Mini Shai-Hulud : le ver npm dévore la chaîne d’approvisionnement

7 Min. de lecture

Le 11 mai 2026, Microsoft Security Research signale une nouvelle vague du ver npm Shai-Hulud : 170 paquets npm et deux paquets PyPI touchés, répartis sur 404 versions malveillantes de paquets. Il s’agit de la première campagne coordonnée frappant simultanément npm et PyPI. Ce n’est pas le chiffre qui est remarquable, mais la conception. Mini Shai-Hulud vole des identifiants et se propage ensuite de lui-même, en empruntant exactement les canaux de publication fiables qui maintiennent ensemble les chaînes d’approvisionnement logicielles modernes.

Les points clés en bref

Le ver se propage de lui-même : Les droits OIDC et de publication volés génèrent de nouvelles versions malveillantes sous de véritables identités de mainteneurs, sans aucun nouvel accès par phishing.
Persistance au-delà du paquet : Le code malveillant s’immisce en partie dans les configurations des développeurs et reste actif, même après la suppression du paquet infecté.
Les tokens sont la porte d’entrée : En privilégiant npm Trusted Publishing et WebAuthn plutôt que des tokens de longue durée, vous fermez le principal vecteur de propagation.

Articles connexes :La faille Splunk sans connexion / Identités machine lors de l’offboarding

Une deuxième vague, plus vaste et coordonnée

Shai-Hulud n’est pas un nouveau venu. Entre le 24 novembre et le 1 décembre 2025, la première vague avait compromis des centaines de paquets npm, dont des composants issus des écosystèmes de Zapier, PostHog, Postman, ENS Domains et AsyncAPI. La variante documentée par Microsoft début mai 2026, baptisée Mini Shai-Hulud, franchit un cap supplémentaire. Elle cible à nouveau des projets de premier plan tels que TanStack, Mistral AI, UiPath, OpenSearch et AntV, et s’étend pour la première fois aux deux grandes registries.

Les 404 versions malveillantes correspondent au nombre d’états de paquets manipulés, répartis sur les 170 paquets npm et les deux paquets PyPI. Ce chiffre n’a rien à voir avec des erreurs HTTP. Pour les équipes de sécurité, cela déplace la recherche : il ne s’agit plus de chercher un seul paquet corrompu, mais de suivre une chaîne de publications qui s’auto-entretiennent.

La mécanique : preinstall s’exécute avant chaque test

L’attaque commence à la faille la plus faible du processus d’installation. Un script malveillant préinstall dans le fichier package.json s’exécute automatiquement lors de l’installation, avant même que les tests ou les vérifications de sécurité ne puissent intervenir. Ce créneau temporel est la clé. À l’intérieur de ce créneau, un script d’initialisation nommé set_bun.js installe, si nécessaire, l’alternative JavaScript Runtime Bun et exécute via celle-ci le véritable payload contenu dans le fichier bun_environment.js.

Ce qui suit est une récolte méthodique. Le code malveillant télécharge un runner GitHub Actions et utilise le scanner de credentials TruffleHog pour extraire des secrets depuis les dépôts et les variables d’environnement. La prise est transférée vers des dépôts contrôlés par les attaquants. Ce qui est volé dépasse largement les tokens npm : accès AWS-SSO et IMDS-v2, identifiants Azure, Google Cloud et Kubernetes, clés SSH, secrets de configuration locaux, voire même des portefeuilles crypto.

404 versions

des configurations de paquets malveillantes ont propagé Mini Shai-Hulud via 170 paquets npm et deux paquets PyPI, identifiées par Microsoft Security Research le 11 mai 2026.

Source : Microsoft Security Blog

Pourquoi le ver survivra même si le paquet a disparu

Le véritable avantage par rapport aux attaques classiques sur la chaîne d’approvisionnement réside dans sa propagation. Mini Shai-Hulud utilise les droits OIDC et de publication volés pour publier de nouveaux releases malveillants sous les identités de mainteneurs authentiques. Grâce à GitHub Trusted Publishing et aux scripts de cycle de vie npm, l’attaque se propage ainsi via les canaux de publication fiables, sans qu’il soit nécessaire aux attaquants de recourir à nouveau au phishing.

Pire encore est la persistance. Selon Microsoft, le code malveillant s’ancre partiellement via des hooks SessionStart dans le fichier .claude/settings.json et via l’interface GraphQL de GitHub. Ainsi, l’attaque persiste dans l’environnement de développement, pas seulement dans la dépendance. Celui qui supprime le paquet infecté et croit avoir terminé ignore le mécanisme qui se déclenche à chaque prochain démarrage de l’outil.

La nouvelle surface d’attaque : outils de développement IA et runtimes alternatifs

C’est exactement ici que réside la leçon qui va au-delà de ce seul incident. Le ver s’appuie non seulement sur des scripts classiques npm, mais aussi sur une runtime alternative avec Bun et les fichiers de hook des outils modernes de codage IA, ainsi qu’un mécanisme de persistance rarement pris en compte lors des audits traditionnels. Une SBOM liste les dépendances, mais elle n’inclut pas les configurations de hook dans l’environnement de développement.

Pour la réponse aux incidents, cela signifie d’élargir le périmètre. Quiconque enquête sur une compromission de la chaîne d’approvisionnement devra désormais également examiner les fichiers de configuration des assistants IA, les fichiers de hook locaux et les runtimes non Node. Ce n’est pas une panique autour de l’IA. C’est simplement l’observation rationnelle selon laquelle la surface d’attaque CI/CD s’est étendue à des outils qui n’existaient pas sur chaque poste de développement il y a deux ans.

Défense : remplacer les tokens, renforcer l’identité, signer la pipeline

La bonne nouvelle est que les mesures les plus efficaces sont des principes, pas des produits. Microsoft et plusieurs entreprises de sécurité comme Akamai, Snyk et StepSecurity, qui ont fait des rapports parallèles à la campagne, convergent vers un noyau cohérent. Les mainteneurs devraient utiliser la publication fiable via npm plutôt que des tokens longue durée, car un token volé est le carburant de la propagation auto-entretenue. Une authentification à deux facteurs basée sur WebAuthn protège mieux qu’un TOTP, qui peut être piraté. Et les signatures des commits rendent visibles les versions falsifiées.

Dans le domaine des utilisateurs, la rapidité compte. Qui pourrait être touché doit tourner immédiatement les données d’accès exposées, sans attendre. La création automatisée d’une SBOM et le scanning sans agent aident à détecter les versions manipulées. Des règles réduisant les points d’entrée peuvent bloquer les scripts obscurcis avant même qu’ils ne s’exécutent. Pour les entreprises allemandes, une couche juridique supplémentaire s’ajoute. NIS2 rend la diligence raisonnable dans la chaîne d’approvisionnement une exigence prouvable. Un incident comme celui-ci est donc à la fois un sujet technique et un sujet de documentation.

Foire aux questions

Qu’est-ce que Mini Shai-Hulud ?

Mini Shai-Hulud est une variante du ver npm Shai-Hulud de 2025. La vague documentée par Microsoft le 11 mai 2026 a compromis 170 packages npm et deux packages PyPI via 404 versions malveillantes, se propageant de manière autonome via les canaux de publication de la chaîne logistique logicielle.

Comment le ver infecte-t-il un système ?

Par un script malveillant preinstall, exécuté automatiquement et avant tous les tests lors de l’installation d’un package. Il installe la runtime Bun, charge un payload et scanne avec TruffleHog pour repérer les données d’accès, qui sont ensuite transmises aux attaquants.

Pourquoi supprimer le package infecté ne suffit-il pas ?

Parce que le code malveillant s’installe en partie en dehors des dépendances, par exemple via des hooks SessionStart dans la configuration des outils de codage basés sur l’IA ou via l’API GitHub-GraphQL. Cette persistance active à chaque démarrage de l’outil, même si le package a été retiré depuis longtemps.

Quelles données d’accès sont concernées ?

Sont volées les tokens npm, les accès AWS-SSO et IMDS-v2, les identifiants Azure, Google Cloud et Kubernetes, les clés SSH, les secrets de configuration locaux et les portefeuilles cryptographiques. Qui soupçonne une compromission doit tourner immédiatement les données d’accès exposées.

Quel impact cet incident a-t-il sur les obligations NIS2 ?

NIS2 exige une diligence raisonnable prouvable dans la chaîne d’approvisionnement. Un incident de chaîne d’approvisionnement de ce type touche ainsi au-delà de la défense technique les obligations de documentation et d’alerte des entreprises concernées.