Un ver npm baptisé Shai-Hulud (également suivi sous le nom ChainDrop) compromet en ce moment des centaines de paquets JavaScript et vole les secrets de vos chaînes CI/CD. Le paquet keyv, téléchargé plus de 150 millions de fois par semaine, figure parmi les victimes. Pour une PME-ETI qui développe en interne ou sous-traite ses applicatifs, ce ver npm transforme un simple npm install en fuite de jetons cloud, GitHub et npm. Voici ce qui se passe et comment couper l’exposition.
Ce que fait le ver npm Shai-Hulud
Contrairement aux compromissions classiques d’un seul paquet, il s’agit ici d’un ver auto-propagateur. La chaîne d’infection est industrialisée :
- Un hook
preinstallse déclenche dès l’installation, avant même que le développeur n’exécute quoi que ce soit. - Le script télécharge le runtime Bun puis exécute une charge utile obfusquée.
- La charge collecte les identifiants accessibles : jetons npm, jetons GitHub, variables d’environnement cloud, secrets de pipelines CI.
- Avec les jetons npm volés, le ver republie des versions trojanisées des paquets appartenant à la victime — d’où la propagation exponentielle, de l’ordre de 50 à 100 nouveaux paquets toutes les quelques minutes.
Les compteurs publics parlent d’eux-mêmes : plus de 2 200 artefacts malveillants répartis sur 444 paquets uniques au moment de l’écriture, dont des dépendances liées à des acteurs majeurs du e-commerce et de la BI.
La nouveauté : des hooks qui ciblent vos agents IA de code
L’élément qui doit alerter les RSSI est ailleurs. Ce ver npm plante des hooks de démarrage automatique dans les répertoires .claude/ et .vscode/ des projets infectés. Autrement dit, il ne se contente pas de piller la machine du développeur : il installe une persistance qui se réveillera la prochaine fois qu’un agent IA de code ou un éditeur ouvrira le dépôt. La surface d’attaque des assistants de développement devient un canal de persistance à part entière, un schéma que nous avions déjà décrit dans notre article sur les extensions IDE et paquets npm piégés.
Autre signal préoccupant : certaines publications malveillantes portaient une provenance OIDC/SLSA valide. La signature cryptographique atteste que le paquet a bien été publié par le pipeline légitime — pipeline qui était lui-même compromis. La provenance prouve l’origine, pas l’innocence.
Pourquoi les PME-ETI sont particulièrement exposées
Une grande entreprise dispose d’un miroir de registre interne et d’une équipe AppSec. Une PME-ETI installe directement depuis le registre public, souvent depuis un poste de développeur qui porte aussi les identifiants de production. Trois facteurs aggravent le risque :
- Le délai de détection : même avec une réaction rapide des plateformes de sécurité, plusieurs minutes de fenêtre suffisent pour exfiltrer un jeton à longue durée de vie.
- Les jetons non expirants : un jeton npm ou un PAT GitHub sans date d’expiration reste exploitable des mois après le vol.
- Les builds automatiques : un pipeline qui se déclenche sur chaque commit rejoue l’installation compromise avec, cette fois, les secrets de production dans l’environnement.
Bloquer le ver npm : les actions à mener cette semaine
1. Désactiver les scripts d’installation
C’est la mesure la plus rentable. Ajoutez ignore-scripts=true dans votre .npmrc global et dans celui de vos runners CI. La quasi-totalité des paquets modernes fonctionne sans script postinstall ; ceux qui en ont besoin s’autorisent au cas par cas. Cette seule ligne neutralise le vecteur preinstall utilisé par ce ver npm.
2. Verrouiller et figer les dépendances
Utilisez npm ci plutôt que npm install en CI, afin de respecter strictement le package-lock.json. Complétez avec une politique de délai de quarantaine : refusez toute version publiée depuis moins de 48 à 72 heures. La grande majorité des campagnes de supply chain npm est détectée dans cette fenêtre.
3. Faire tourner tous les secrets exposés
Si l’un de vos projets a installé une dépendance affectée depuis le début de la campagne, considérez les secrets comme compromis. Priorité à la rotation :
- Jetons npm et PAT GitHub (avec passage systématique à une expiration courte)
- Clés d’accès AWS / Azure / GCP présentes dans l’environnement de build
- Variables de secrets des runners GitHub Actions et GitLab CI
- Clés SSH de déploiement
4. Auditer les répertoires d’agents IA
Recherchez dans tous vos dépôts les fichiers de configuration .claude/ et .vscode/ modifiés récemment et non attribuables à un commit légitime. Un hook de démarrage inconnu dans ces dossiers doit être traité comme une backdoor, pas comme une préférence d’éditeur. Nos recommandations générales de durcissement figurent dans notre article dédié à la sécurisation de la supply chain web.
5. Surveiller la sortie réseau des postes de développement
Un poste de développeur qui contacte soudainement un domaine inconnu pendant un npm install, ou qui télécharge un runtime non prévu, est un signal fort. Journalisez les connexions sortantes des machines de build et alertez sur les nouveaux domaines.
Le fond du problème : la confiance transitive
Un projet Node moyen embarque plusieurs centaines de dépendances transitives. Vous n’auditez pas 800 mainteneurs, vous faites confiance à un graphe. Ce ver npm exploite précisément cette structure : il lui suffit d’un mainteneur dont le jeton fuit pour atteindre tous les projets en aval. La réponse défensive n’est donc pas de tout auditer, mais de réduire la valeur de ce qu’un attaquant obtient : secrets à durée de vie courte, exécution de scripts désactivée, séparation stricte entre poste de développement et identifiants de production.
Chez ucyber.ai, notre SOC agentique corrèle ces signaux — nouveaux domaines contactés en build, création de jetons anormale, modifications de fichiers de configuration d’agents — pour transformer une campagne de supply chain en alerte exploitable plutôt qu’en post-mortem. Face à un ver npm qui se propage en minutes, le temps de détection compte plus que l’exhaustivité de l’inventaire.