Shai-Hulud 2.0 : ce que le ver npm auto-propagé nous a appris sur la défense supply-chain en 2026

Ce que Shai-Hulud 2.0 a fait et pourquoi cela compte

Le premier ver Shai-Hulud a été divulgué en septembre 2025 — la chronologie Unit 42 et l'avis CISA ont catalogué plus de 500 paquets compromis et identifié la campagne de phishing à récolte d'identifiants qui l'a amorcé. C'était sans précédent à l'époque.

Shai-Hulud 2.0, ou « la seconde venue », a émergé le 24 novembre 2025 et était plus automatisé, plus agressif et plus destructeur. Datadog Security Labs et le blog Microsoft Security du 9 décembre 2025 ont documenté les mécaniques :

• Quand un paquet compromis est installé, un script preinstall dépose deux fichiers malveillants (`setup_bun.js` et `bun_environment.js`).
• Le script récolte les credentials locaux : tokens npm, credentials Git, secrets cloud AWS, Google Cloud et Azure.
• Les credentials volés sont exfiltrés vers un dépôt GitHub public étiqueté « Sha1-Hulud: The Second Coming ».
• Utilisant le token npm volé, le ver identifie les autres paquets maintenus par le développeur compromis et publie automatiquement des versions backdoorées — jusqu'à 100 paquets par développeur infecté.
• Mécanisme destructif. Si le ver ne peut pas exfiltrer les données ou se propager (pas de token GitHub ou npm, egress réseau bloqué), la charge utile écrase et efface tous les fichiers écrivables dans le répertoire home du développeur.

Elastic, Sonatype et ReversingLabs ont tous produit des write-ups techniques indépendants dans les 48 premières heures, et le guide de défense communautaire dont-be-shy-hulud sur GitHub est devenu la référence de remédiation de facto.

Pourquoi npm a révoqué tous les tokens legacy

Le 9 décembre 2025, npm a pris la rare décision de révoquer en masse tous les tokens « classiques » legacy à travers le registry. D'après l'analyse Microsoft, le raisonnement était direct : les tokens classiques fournissaient une autorité de publication large et durable que le ver utilisait pour se propager plus vite que la révocation manuelle ne pouvait suivre. En forçant chaque mainteneur vers des tokens à portée limitée et à durée brève, npm a supprimé l'accélérateur principal.

C'est le changement structurel le plus conséquent de l'écosystème npm depuis des années. Chaque pipeline CI/CD qui publiait un paquet avec un token classique s'est cassé le 9 décembre. La course à la migration — et les pipelines encore cassés aujourd'hui parce que personne n'a remarqué — est en elle-même un indicateur d'hygiène supply-chain.

Ce que chaque équipe d'ingénierie doit faire en 2026

Les mécaniques du ver se généralisent au-delà d'un incident unique. Tout futur ver de type npm suivra le même modèle : compromettre un mainteneur, voler son token, pousser des versions backdoorées de ses paquets, répéter. La défense doit donc être structurelle, pas réactive.

• Retirer les tokens npm classiques partout. Auditer chaque pipeline CI/CD, workstation développeur et credential store pour les entrées `_authToken` dans les fichiers `.npmrc`. Remplacer par des granular access tokens (GAT) à portée limitée à des paquets spécifiques avec des fenêtres d'expiration brèves, ou par des flux trusted-publisher (OIDC) quand disponibles.
• MFA résistante au phishing pour chaque compte mainteneur. La compromission Shai-Hulud originale remontait à une campagne de phishing usurpant les mises à jour MFA npm. Les clés FIDO2 matérielles pour npm, GitHub et tout compte package registry sont désormais la barre minimum pour quiconque publie du code que des utilisateurs en aval installent.
• Désactiver les scripts preinstall et postinstall par défaut. `npm install –ignore-scripts` devrait être le défaut en CI/CD, pas l'exception. Exécuter des scripts uniquement pour des paquets vérifiés via une allowlist. Beaucoup d'organisations configurent cela dans un `.npmrc` partagé à travers le parc.
• Passer à des credentials CI/CD éphémères. Les tokens à durée longue dans les pipelines sont comment cette classe d'attaque se propage latéralement dans le système de build. Les credentials à courte durée liés à une workload-identity (OIDC de GitHub Actions vers npm, fédération de rôle IAM vers le cloud) suppriment la surface d'attaque statique.
• Détecter les anomalies preinstall en CI. Monitorer les appels réseau au moment de l'install, les écritures de fichiers dans `$HOME`, et les créations inattendues de dépôts GitHub depuis les runners CI. Datadog, Elastic, Snyk, Socket et Aikido ont tous publié des règles de détection pour les indicateurs Shai-Hulud 2.0 adaptables à de futures variantes.
• Figer les versions de dépendances avec des lockfiles. `package-lock.json` ou `pnpm-lock.yaml` préviennent les pulls opportunistes d'une version malveillante juste publiée. Combiné avec la provenance signée via l'intégration sigstore de npm, cela élève matériellement la barre.
• Maintenir un environnement d'installation en quarantaine pour les tests de première exécution. Les nouvelles dépendances devraient d'abord être installées dans une VM isolée sans credentials persistants. Tout paquet dont la phase d'install atteint un endpoint réseau inattendu ou écrit hors de son répertoire devrait déclencher une investigation avant d'atterrir dans l'environnement principal.

Le playbook de réponse immédiate si vous pensez être infecté

Si un développeur soupçonne que Shai-Hulud 2.0 (ou une variante) est actif sur sa machine, les recommandations d'incident StepSecurity et le blog Microsoft convergent sur trois actions immédiates :

1. Ne pas lancer `npm install` sur aucun projet. Si possible, se déconnecter du réseau. Cela prévient à la fois la propagation et le déclenchement du mécanisme destructif si la charge utile n'a pas encore terminé.
2. Révoquer tous les tokens développeur — npm, GitHub, AWS, Google Cloud, Azure — immédiatement. Révoquer d'abord, faire tourner ensuite. Si vous tournez avant de révoquer, le ver peut voler les nouveaux credentials.
3. Nettoyer la machine avant de faire tourner les credentials. Réinstaller l'OS ou restaurer depuis une sauvegarde connue saine. N'émettre de nouveaux credentials qu'une fois l'environnement de développement vérifiablement exempt de la charge utile.

Pour les organisations, ajouter : publier un avis CISO à l'équipe ingénierie dans les 24 heures, vérifier tous les credentials de publication de paquets partagés, et auditer les 30 derniers jours de nouveaux paquets publiés depuis les comptes organisationnels.

Ce que cela signifie pour la conversation supply-chain plus large

Les perspectives 2026 de Dark Reading sur les vers supply-chain énoncent le point structurel sans détour : Shai-Hulud a démontré, à l'échelle, que l'écosystème de paquets dispose d'un mécanisme de réplication à disposition de tout attaquant suffisamment motivé. npm a été le premier à cause de sa taille et de la permissivité des scripts preinstall, mais PyPI, RubyGems, Maven Central et NuGet partagent des faiblesses structurellement similaires.

Trois changements directionnels devraient figurer au tableau de bord 2026 de chaque CISO.

• Traiter les package registries comme une infrastructure supply-chain de production. Accès, audit et hygiène devraient recevoir la même rigueur que les bases de données de production.
• Adopter la provenance signée partout où disponible. L'intégration sigstore de npm, les trusted publishers Python PEP 740 et les programmes similaires dans d'autres écosystèmes ferment l'écart de responsabilisation.
• Interroger les fournisseurs sur leur hygiène package registry. Les évaluations de risque tierce-partie en 2026 devraient inclure des questions spécifiques sur MFA, portée des tokens et signature de provenance sur les pipelines de build du fournisseur.

Où cela laisse les équipes d'ingénierie

Shai-Hulud 2.0 est l'incident supply-chain le plus clair que la plupart des dirigeants ingénierie aient vu, et il ne sera pas le dernier. Le travail défensif — migration des tokens, MFA résistante au phishing, `–ignore-scripts`, provenance — est bien compris, de plus en plus instrumenté, et gratuit ou peu coûteux dans chaque cas. Les organisations qui ont traité l'incident de novembre 2025 comme un wake-up call sont en bien meilleure forme que celles qui l'ont traité comme le problème d'un autre. La question pour chaque CTO qui lit ceci en avril 2026 est simple : combien des étapes du playbook ci-dessus ont réellement été livrées ?

À retenir : Traiter Shai-Hulud 2.0 comme l'incident de référence pour la défense supply-chain logicielle. Retirer les tokens npm classiques, imposer la MFA matérielle FIDO2 à chaque mainteneur et développeur avec droit de publication, définir par défaut CI/CD à `npm install –ignore-scripts` et passer à des credentials éphémères à courte durée pour tous les pipelines de build. Les dirigeants ingénierie algériens devraient livrer ces changements ce trimestre, pas après la prochaine variante.

Sources et lectures complémentaires

• Le ver npm Shai-Hulud 2.0 : analyse et ce qu'il faut savoir — Datadog Security Labs
• Shai-Hulud 2.0 : guide de détection, d'investigation et de défense — Microsoft Security Blog
• Le ver « Shai-Hulud » compromet l'écosystème npm — Unit 42 (Palo Alto)
• Naviguer le ver Shai-Hulud 2.0 — Elastic Security Labs
• Comprendre l'attaque du ver npm Shai-Hulud — Sonatype
• Shai-Hulud 2.0 se propage. Voici ce qu'il faut savoir — ReversingLabs
• Compromission supply-chain généralisée impactant l'écosystème npm — CISA
• Shai-Hulud : ver auto-répliquant compromettant 500+ paquets NPM — StepSecurity
• Vers supply-chain en 2026 : ce que Shai-Hulud a enseigné aux attaquants — Dark Reading
• dont-be-shy-hulud — Guide de défense communautaire (GitHub)