TL;DR
Mini Shai-Hulud montre comment un compromis npm se propage après la première publication malveillante. L'attaquant n'a pas besoin de compromettre directement chaque application en aval. Il lui faut un compte mainteneur, un chemin CI ou un point d'exécution pendant l'installation qui expose des identifiants.
Au 2026-05-19, Socket a signalé 639 versions de paquets compromises dans 323 paquets uniques lors d'une vague Mini Shai-Hulud concentrée autour de l'écosystème @antv. L'ensemble touché comprenait des paquets de graphiques, de visualisation, de cartographie et des wrappers React utilisés par des équipes d'ingénierie qui ne considèrent pas toujours ces dépendances comme critiques pour la sécurité.
Le modèle est le vrai problème. npm est utile parce qu'il centralise la publication, le scan et le retrait. Cette même centralisation devient dangereuse lorsque des scripts de cycle de vie, la publication de confiance et les identifiants de mainteneurs sont abusés pour transformer les paquets en réseau de distribution.
Ce qui s'est passé dans la vague AntV
La vague AntV a utilisé un point d'entrée npm classique : l'exécution à l'installation. L'analyse de Socket décrit un payload index.js à la racine qui modifiait package.json pour s'exécuter pendant preinstall.
C'est important parce que npm install, pnpm install et yarn install ne sont pas de simples étapes de téléchargement. Les scripts de cycle de vie d'un paquet peuvent exécuter du code avant qu'un développeur examine le contenu du paquet ou lance l'application.
Le payload était fortement obfusqué. Socket a rapporté un décodage de chaînes à l'exécution, une exfiltration chiffrée, l'utilisation de l'API GitHub, l'utilisation de l'API du registre npm et un chemin HTTPS d'exfiltration codé en dur. Le but n'était pas seulement d'exécuter un malware une fois. Le but était de collecter des identifiants permettant au malware de publier à nouveau.
Comment Mini Shai-Hulud crée l'effet boule de neige
Le payload vise les environnements développeur et CI/CD parce qu'ils détiennent le pouvoir de publication. Une application web peut seulement avoir besoin d'un paquet de graphiques, mais la machine ou le workflow qui l'installe peut aussi avoir accès à npm, GitHub, AWS, Kubernetes, Vault, SSH, Docker ou à des identifiants de bases de données.
Les identifiants ciblés incluent :
- Tokens GitHub et matériel OIDC de GitHub Actions
- Tokens de publication npm
- Identifiants AWS et métadonnées d'instance
- Fichiers de comptes de service Kubernetes
- Tokens HashiCorp Vault
- Fichiers d'authentification Docker
- Clés SSH et clés privées
- Chaînes de connexion à des bases de données
Une fois que le malware trouve des identifiants npm utilisables, il peut énumérer les paquets que la victime peut maintenir, modifier les tarballs, ajouter un hook d'installation, incrémenter les versions et republier des paquets compromis sous une identité de mainteneur fiable.
Pourquoi Axios et TanStack comptent
La vague AntV n'est pas isolée. L'écosystème npm a connu une série d'incidents où des attaquants abusent de mainteneurs fiables, de dépendances transitives et de l'automatisation CI/CD.
L'analyse Axios de Datadog décrit comment un attaquant a détourné un compte mainteneur Axios le 2026-03-31 et publié des versions malveillantes de axios ajoutant la dépendance cheval de Troie plain-crypto-js. Cette dépendance téléchargeait et exécutait un cheval de Troie d'accès distant multiplateforme pendant l'installation.
L'analyse TanStack d'Endor Labs montre une autre leçon. TanStack utilisait la publication de confiance OIDC de npm, qui supprime les tokens npm statiques de longue durée. L'attaquant a tout de même obtenu un chemin de publication valide via des mécaniques de dépôt et de workflow. Le résultat : des versions malveillantes dans le namespace TanStack avec une provenance en apparence valide.
Le point commun n'est pas un seul outil cassé. C'est la quantité d'autorité concentrée dans les environnements développeur et les workflows de release.
npm est à la fois un outil de défense et un chemin d'attaque
npm donne aux défenseurs un point central pour inspecter les paquets, signaler les malwares, déprécier des releases et révoquer des tokens. Ce modèle centralisé est préférable à des téléchargements opaques et isolés.
Mais npm donne aussi aux attaquants une couche centrale de distribution. Si un paquet fiable publie une version malveillante, les utilisateurs en aval peuvent la récupérer via des installations ordinaires, des mises à jour de lockfile, des rebuilds CI ou la résolution de dépendances transitives.
| Fonction npm | Valeur défensive | Valeur pour l'attaquant |
|---|---|---|
| Registre central | Permet le scan, les avis et le retrait | Donne une large distribution aux versions malveillantes |
| Scripts de cycle de vie | Supportent le setup de paquets et les builds natifs | Exécutent du code attaquant pendant l'installation |
| Comptes mainteneurs | Permettent de publier rapidement | Transforment une identité compromise en nombreux paquets empoisonnés |
| Publication de confiance | Réduit l'exposition des tokens longue durée | Peut être abusée si le workflow ou la frontière de confiance est compromis |
La leçon n'est pas d'abandonner npm. La leçon est de réduire la confiance automatique à chaque étape où du code s'exécute.
Ce que les équipes doivent faire maintenant
Commencez par l'environnement de build et de développement. Toute machine ou tout runner CI qui a installé un paquet touché doit être considéré comme exposé jusqu'à la revue des identifiants.
- Vérifier les lockfiles et les logs du gestionnaire de paquets pour les versions affectées installées le 2026-05-19 ou après
- Faire tourner les identifiants npm, GitHub, cloud, Vault, SSH, Docker et bases de données accessibles depuis ces systèmes
- Auditer les paquets maintenus pour repérer des versions inattendues, des hooks d'installation ou des dépendances git ajoutées
- Utiliser des installations strictes avec lockfile comme
npm ci,pnpm install --frozen-lockfileouyarn install --frozen-lockfile - Désactiver les scripts de cycle de vie lorsque c'est possible avec
--ignore-scripts, surtout dans les jobs CI qui n'ont pas besoin de builds natifs - Ajouter des délais de refroidissement ou des revues afin que les versions fraîchement publiées n'entrent pas automatiquement en production
- Surveiller le trafic sortant des environnements CI et des postes développeur vers des chemins suspects d'exfiltration
Ces contrôles réduisent la probabilité qu'un paquet malveillant devienne un incident de publication sur tous les paquets maintenus par un développeur.
Où cside s'insère
cside n'est pas un scanner de registre npm et ne remplace pas le durcissement CI/CD. Vous avez toujours besoin de scan de dépendances, de lockfiles, d'hygiène des tokens et de contrôles stricts de release.
cside couvre la partie de la chaîne d'approvisionnement qui s'exécute dans le navigateur. De nombreux sites de production chargent des scripts tiers, des SDK, des payloads de tag managers, de l'analytics et du code livré dynamiquement qui ne se comporte jamais comme une dépendance npm fixe. Un paquet ou un fournisseur peut sembler légitime au build et livrer plus tard un comportement risqué dans le navigateur.
cside surveille le comportement des scripts lorsqu'ils s'exécutent dans le navigateur de l'utilisateur. Cela inclut les changements de scripts, l'accès inattendu aux données, les tentatives suspectes d'exfiltration et l'activité côté navigateur que les scanners de dépendances ne peuvent plus voir une fois le code en production.
La bonne défense est en couches : sécuriser le chemin du registre, durcir la CI, faire tourner les secrets rapidement et surveiller le comportement en runtime là où les utilisateurs exécutent réellement le code.
