Ce matin, nous avons été alertés d'une attaque de grande envergure contre npm. Il semble que ce soit l'œuvre des mêmes acteurs de la menace derrière l'attaque Nx du 27 août 2025. Cela a été initialement publié par Socket et StepSecurity qui ont noté que 40 packages avaient été compromis ; depuis, 147 packages supplémentaires ont été infectés par des malwares, y compris des packages de CrowdStrike.
L'ampleur, la portée et l'impact de cette attaque sont importants. Les attaquants utilisent en grande partie le même playbook que l'attaque originale, mais ils ont intensifié leur jeu. Ils l'ont transformé en un ver complet, qui effectue ces actions automatiquement :
- Voler des secrets et les publier publiquement sur GitHub
- Exécuter trufflehog et interroger les points de terminaison de métadonnées du cloud pour collecter des secrets
- Tenter de créer une nouvelle action GitHub avec un mécanisme d'exfiltration de données via webhook[.]site
- Itérer sur les dépôts GitHub auxquels un utilisateur a accès et les rendre publics
Depuis notre alerte initiale ce matin, nous avons confirmé les comportements supplémentaires et les détails importants suivants. Pour ceux qui l'ignorent, Shai Hulud est le nom du ver dans la franchise Dune. Une indication claire de l'intention des attaquants.
Pour éviter d'être compromis par des packages comme celui-ci, découvrez Aikido safe-chain !
Ce que fait le ver
- Collecte : analyse l'hôte et l'environnement CI à la recherche de secrets — process.env, analyse avec TruffleHog, et points de terminaison de métadonnées du cloud (AWS/GCP) qui renvoient les identifiants d'instance/de service.
- Exfiltration (1) — Dépôt GitHub : crée un dépôt nommé Shai-Hulud sous le compte compromis et y commet un dump JSON contenant les informations système, les variables d'environnement et les secrets collectés.
- Exfiltrer (2) — GitHub Actions → webhook: dépose un workflow
.github/workflows/shai-hulud-workflow.ymlqui sérialise${{ toJSON(secrets) }}, les envoie par POST à un attaquantwebhook[.]siteURL et écrit une copie en double base64 dans les logs des Actions. - Propagation : utilise tous les tokens npm valides qu'il trouve pour énumérer et tenter de mettre à jour les packages que le mainteneur compromis contrôle (propagation dans la chaîne d'approvisionnement).
- Amplification : parcourt les dépôts accessibles de la victime, les rendant publics ou en ajoutant le workflow/la branche qui déclenchera d'autres exécutions et fuites.
Fuite de secrets
Comme avec l'attaque Nx originale, nous observons les attaquants mener une attaque de type « smash-and-grab ». La charge utile malveillante publie à la fois un dépôt « Shai-Hulud » avec des identifiants/tokens volés, et elle parcourra un compte GitHub pour transformer les dépôts privés en dépôts publics :
Auto-propagation via npm
L'une des caractéristiques les plus frappantes de cette attaque est qu'elle se comporte comme un véritable ver. Plutôt que de s'appuyer sur un seul package infecté pour se propager, le code est conçu pour se republier dans d'autres packages npm appartenant au mainteneur compromis.
Voici comment fonctionne la logique du ver :
- Télécharger un tarball cible – il récupère une version de package existante depuis le registre npm.
- Modifier
package.json– le ver incrémente la version de patch (par ex.1.2.3 → 1.2.4) et insère un nouveau hook de cycle de vie (post-installation) - Copier sa propre charge utile – le script en cours d'exécution (
process.argv[1])bundle.js) est écrit dans le tarball en tant que - Republier le package troyanisé – le tarball modifié est gzippé et renvoyé vers npm en utilisant les identifiants du mainteneur.
Ce cycle permet au malware d'infecter continuellement chaque package auquel un mainteneur a accès. Chaque package publié devient un nouveau vecteur de distribution : dès qu'il est installé, le ver s'exécute, se réplique et se propage davantage dans l'écosystème.
En bref : l'attaquant n'a pas besoin de cibler manuellement les packages. Une fois qu'un seul environnement est compromis, le ver automatise sa propagation en tirant parti des droits de publication du mainteneur.
Pour une analyse complète du malware, nous vous recommandons de consulter le post getsafety.
Packages impactés
Histoire en cours de développement…
Conseils de remédiation
- Vérifiez les versions que vous utilisez
- Nettoyez votre cache npm
- Réinstallez tous les paquets de votre dépôt
- Assurez-vous d'utiliser un fichier de verrouillage de paquet et des versions épinglées
Comment savoir si vous êtes affecté en utilisant Aikido :
Si vous êtes un utilisateur d'Aikido, consultez votre flux central et filtrez les problèmes de logiciels malveillants. La vulnérabilité sera affichée comme un problème critique 100/100 dans le flux. Conseil : Aikido réanalyse vos dépôts chaque nuit, bien que nous recommandions de déclencher également une réanalyse complète.
Si vous n'êtes pas encore un utilisateur d'Aikido, créez un compte et connectez vos dépôts. Notre couverture propriétaire des logiciels malveillants est incluse dans le plan gratuit (aucune carte de crédit requise).
Pour une protection future, envisagez d'utiliser Aikido SafeChain (open source), un wrapper sécurisé pour npm, npx, yarn... Safechain s'intègre dans vos workflows actuels, il fonctionne en interceptant les commandes npm, npx, yarn, pnpm et pnpx et en vérifiant les paquets pour détecter les logiciels malveillants avant l'installation, en se basant sur Aikido Intel - Renseignement sur les menaces open source. Arrêtez les menaces avant qu'elles n'atteignent votre machine.
