Shai-Hulud : le worm qui a infecté 314 packages npm en 12 jours

Entre le 29 avril et le 11 mai 2026, un worm baptisé Shai-Hulud a contaminé plus de 314 packages npm et 2 packages PyPI, totalisant 404 versions malicieuses. Parmi les projets touchés : TanStack, OpenSearch (1,3 million de téléchargements npm par semaine), UiPath, et indirectement Mistral AI. C'est à ce stade l'attaque supply chain JS la plus large jamais documentée.

Ce n'est pas un publish malicieux isolé. C'est un ver auto-propageant qui exploite la confiance entre packages pour se diffuser.

Le mode opératoire en clair

Trois étapes :

1. Vol de tokens : un package légitime est compromis. Au moment de l'install, le payload exfiltre les tokens GitHub, npm, secrets CI/CD, clés cloud depuis l'environnement du dev ou du runner.
2. Propagation : avec les tokens npm volés, le worm publie une nouvelle version malicieuse des packages que les victimes maintiennent. Si vous mainteniez 5 packages, ils sont tous compromis dans les heures qui suivent.
3. Persistance : exfiltration vers un serveur C2 distant + création de webhooks GitHub sur les repos accessibles pour maintenir un canal de contrôle.

Le worm s'appelle Shai-Hulud en référence aux vers géants de Dune. Choix de nom volontairement mémorable — c'est aussi un marqueur de groupe.

Pourquoi ça a marché à cette échelle

Le postinstall reste l'angle mort de npm

Chaque package npm peut exécuter du code arbitraire au moment de l'install via le hook postinstall. En 2026, la majorité des CI laissent ce mécanisme activé par défaut. Un seul npm install dans un container avec accès au filesystem et aux variables d'env, c'est une porte ouverte.

Les tokens npm ont rarement des scopes serrés

Un token de publication npm permet souvent de publier tous les packages que le compte maintient. Pas de granularité par package. Quand le worm capture un token, il peut donc se répliquer immédiatement sur la totalité du périmètre de maintenance de la victime.

Le graph de dépendances est trop dense

Un projet front moderne charge 800-2000 packages transitifs. Une seule compromission dans cette arborescence atteint potentiellement des dizaines de milliers d'utilisateurs en aval.

Ce que je conseille de faire cette semaine

1. Vérifier si vous êtes touché

• Lister vos dépendances directes et transitives installées entre le 29 avril et le 11 mai 2026.
• Croiser avec la liste des packages compromis publiée par Wiz, Orca Security, SafeDep et Unit 42. Plusieurs équipes maintiennent des listes consolidées à jour.
• Si vous trouvez un match : rotation de tous les secrets accessibles aux runners pendant cette fenêtre, sans exception.

2. Verrouiller le postinstall

• npm config set ignore-scripts true au niveau global de vos runners.
• Allowlist explicite des packages autorisés à scripter (@types/* n'en a typiquement pas besoin, certains binaires comme esbuild ou puppeteer oui).
• Auditer la liste : si elle a plus de 30-40 entrées, le périmètre est probablement trop large.

3. Resserrer les tokens

• Migrer tous vos PAT GitHub vers le format fine-grained ou GitHub Apps avec scope par dépôt.
• Sur npm, activer la publication par OIDC depuis GitHub Actions (token éphémère, plus de long-lived secret).
• Rotation immédiate des tokens dont vous n'êtes pas certains.

4. Mettre une quarantaine sur le registre

Un proxy interne (Verdaccio, Artifactory, Sonatype Nexus) qui refuse de servir les versions de moins de 48 à 72h coupe la fenêtre d'exposition. La majorité des publish malicieux sont identifiés et retirés sous 24h par les chercheurs et par npm. La quarantaine vous met de l'autre côté de ce délai.

Ce que Shai-Hulud change dans le threat model

Avant Shai-Hulud, le risque "package malicieux" était souvent rangé en rare et statique : un package isolé, publié une fois, détecté assez vite. Le worm change la nature du risque :

• Auto-propageant : un seul mainteneur compromis peut contaminer toute sa famille de packages en quelques heures.
• Multi-écosystème : les variantes touchent npm et PyPI dans la même campagne.
• Ciblé sur les tokens : l'objectif n'est plus seulement le data exfil, c'est l'extension du réseau.

C'est un saut comparable à ce qu'a été NotPetya pour le ransomware en 2017 : pas une nouvelle technique, mais l'industrialisation d'un schéma connu à une échelle qui change la posture défensive attendue.

Ce qui reste valable et ce qui ne l'est plus

Valable : SBOM, scan SCA, lockfile committé, secret scanning. Tout ce que les guides supply chain recommandent depuis 5 ans tient bon.

Plus suffisant seul : se reposer uniquement sur la détection après publish. Quand le worm peut publier des dizaines de versions en parallèle sur des comptes maintenus par des humains de confiance, la détection a un délai irréductible. Il faut la coupler avec une politique de quarantaine et de scoping fin des tokens.

Pour la lecture de la compromission Mistral via le même worm, Mistral AI et la compromission TanStack. Pour la vuln GitHub Actions exploitée en chaîne, pull_request_target : la vuln que 60% des repos publics ont encore.