L'écosystème JavaScript/npm est confronté à une nouvelle référence en matière de menaces liées à la chaîne d'approvisionnement avec la résurgence de Shai-Hulud 2.0 le 24 novembre 2025. Ce ver auto-propagateur cible spécifiquement les mainteneurs open source et les paquets qu'ils publient. Cette nouvelle variante marque le passage de paquets malveillants isolés à un mécanisme d'infection coordonné et automatisé.
L'impact est déjà considérable. Des centaines de paquets npm et des dizaines de milliers de référentiels GitHub ont été touchés, créant un « rayon d'action » sans précédent pour une attaque de la chaîne logistique JavaScript. Pour les lecteurs familiers avec l'analyse de Shai-Hulud 1.0OPSWAT, la version 2.0 élargit considérablement les capacités et l'échelle opérationnelle du ver : exécution plus précoce, propagation plus large et plus résistante aux mesures correctives standard, le faisant passer d'une menace préoccupante à un incident à l'échelle de l'écosystème.
Shai-Hulud 2.0 En bref
- Ver auto-propagateur : Shai-Hulud 2.0 vole les identifiants GitHub, se reconditionne et se republie dans l'ensemble du portefeuille npm d'un mainteneur.
- Propagation massive :plus de 700 paquets npm infectés, plus de 25 000 dépôts GitHub, 500 mainteneurs affectés ; plus de 1 000 nouveaux dépôts ajoutés toutes les 30 minutes (Wiz).
- Impact inter-écosystèmes : également observé dans Maven/Java via la mise en miroir automatisée npm-to-Maven.
- Risques principaux : exposition CI/CD, compromission de secrets, exécution au moment de l'installation et registres corrompus.
- Défense : précision du SBOM, vérification de la provenance, surveillance de l'exécution et hygiène stricte des jetons/secrets.
Portée et escalade : quelle est l'étendue des dégâts ?
L'ampleur et la rapidité de la propagation de Shai-Hulud 2.0 ont dépassé tout ce qui avait été observé lors des incidents récents touchant la chaîne logistique. Ce qui avait commencé comme une compromission ciblée du npm s'est rapidement transformé en une infection systémique et multiplateforme touchant des milliers de projets et des centaines de responsables de maintenance.
Contrairement aux logiciels malveillants npm classiques, qui impliquent généralement un seul paquet trojanisé, Shai-Hulud 2.0 se comporte comme un ver. Après avoir compromis un développeur, il vole les identifiants GitHub, se reconditionne et se republie dans l'ensemble des paquets du mainteneur, transformant chaque victime en un nouveau point de distribution. Il en résulte une propagation rapide et exponentielle dans tout l'écosystème.
Paquets compromis
Des centaines de paquets npm ont été compromis. Parmi eux figurent des projets très visibles gérés par des organisations bien établies, ce qui amplifie l'exposition en aval.
Propagation rapide et exponentielle
Le ver a été observé générant plus de 1 000 nouveaux dépôts GitHub malveillants toutes les 30 minutes (Wiz), alimentés par la publication automatisée à partir d'identifiants volés. Chaque nouvelle victime devient un nœud de propagation, multipliant l'impact total à chaque cycle.
Secrets révélés
Le vol d'identifiants dans le cadre de Shai-Hulud 2.0 s'avère particulièrement préjudiciable. Parmi les secrets divulgués qui ont été vérifiés, on compte plus de 1 500 identifiants et jetons provenant de grandes plateformes telles que GitHub, AWS, Google Cloud et Azure.
Ce volume de jetons sensibles représente une compromission multi-cloud étendue, susceptible d'être exploitée à long terme.
Efforts d'assainissement
Heureusement, plusieurs mainteneurs de renom tels que Zapier, PostHog et Postman ont déjà repris le contrôle de leurs paquets. Les versions malveillantes ont été supprimées de npm, et de nombreux dépôts affectés sont en cours de récupération ou de nettoyage.
Cependant, l'incident est toujours en cours. Même avec une remédiation rapide, les organisations doivent continuer à surveiller l'état des dépendances, les pipelines CI et les comptes GitHub afin de détecter tout signe de fuite supplémentaire d'informations d'identification ou de republication automatisée.
Impact inter-écosystèmes : npm → Maven/Java
Il convient de noter que cette vague a également eu un impact sur d'autres écosystèmes tels que Maven/Java grâce à la conversion automatisée des artefacts npm vers Maven (JFrog) .
-
Si npm reste la cible principale de Shai-Hulud 2.0, cette vague a démontré le risque de propagation entre les écosystèmes, en particulier vers les projets Java/Maven. Les chercheurs en sécurité ont identifié l'artefact Maven malveillant :
org.mvnpm:posthog-node:4.18.1qui contient la même charge utile (configuration_bun.jsetbun_environnement.js) trouvés dans des paquets npm compromis (Les actualités des hackers) .
- Mécanisme : des outils de pontage automatisés reconstruisent les paquets npm sous forme d'artefacts Maven pour les projets Java. Les équipes qui n'utilisent pas directement Node.js peuvent être exposées si leurs projets s'appuient sur ces artefacts mis en miroir.
Cela démontre le risque indépendant de l'écosystème que représentent les attaques contre la chaîne d'approvisionnement. Même les projets qui n'utilisent pas directement npm peuvent hériter de ce risque par le biais d'outils automatisés.
Shai-Hulud 2.0 démontre que les vers modernes qui affectent la chaîne logistique sont des menaces multi-étapes qui tiennent compte de l'environnement : ils s'adaptent aux machines des développeurs et aux pipelines CI/CD, collectent les identifiants à la fois comme charge utile et comme mécanisme de propagation, et incluent des comportements de secours pour garantir leur propagation ou leur impact destructeur. Leur détection nécessite une surveillance du comportement d'exécution à toutes les étapes, et pas seulement une analyse statique du code.
Mécanique technique : comment fonctionne le ver
| Scène | Que se passe-t-il ? |
|---|---|
| 1. Accès initial et déploiement | Les pirates exploitent les comptes compromis des responsables de maintenance npm pour diffuser des paquets contenant configuration_bun.js et bun_environnement.js, exécuté automatiquement via un préinstaller crochet entre les machines des développeurs et les pipelines CI/CD. |
| 2. Initialisation furtive du runtime | Le chargeur détecte l'environnement hôte, initialise le runtime Bun et exécute la charge utile en arrière-plan de manière silencieuse afin que les installations semblent normales. |
| 3. Empreinte environnementale et élévation des privilèges | La charge utile identifie les plateformes CI, tente d'obtenir un accès root sans mot de passe via Docker sur les runners Linux et peut modifier les règles DNS ou iptables pour contrôler les flux réseau. |
| 4. Collecte d'identifiants et de secrets | La charge utile collecte les variables d'environnement et les clés cloud, exécute TruffleHog pour découvrir les secrets locaux, extrait les identifiants AWS/Azure/GCP et injecte des workflows temporaires pour récupérer les secrets GitHub. |
| 5. Exfiltration et persistance | Les données volées sont encodées en triple base64 et téléchargées vers un nouveau référentiel dans le compte de la victime, tandis que la persistance est établie via un runner et un workflow malveillants auto-hébergés. |
| 6. Propagation des vers (réplication) | À l'aide de jetons npm volés, le ver clone les paquets de la victime, injecte des fichiers et des hooks malveillants, modifie les versions et les republie afin de se propager de manière autonome. |
| 7. Repli destructeur | Si aucune information d'identification ne peut être récupérée, le ver déclenche une routine destructrice qui efface définitivement le répertoire personnel de l'utilisateur. |
Risques liés au CI/CD mis en évidence par l'incident PostHog
La violation de PostHog démontre la subtilité de l'exposition CI/CD :
- Les pull requests malveillantes ont exploité pull_request_target dans GitHub Actions.
- Un bot PAT a été exfiltré, ce qui a ensuite permis la publication de SDK npm trojanisés.
Les workflows CI/CD, même automatisés, constituent des surfaces d'attaque à haut risque. Limitez les scripts, minimisez l'exposition des jetons et imposez des identifiants à durée de vie limitée.
Limites des moyens de défense traditionnels
- La fixation des dépendances peut échouer en raison de dépendances transitives.
- Les scanners SCA statiques ne peuvent pas détecter les codes trojanisés récemment publiés sous des noms de paquets légitimes.
- L'utilisation abusive des jetons via les pipelines CI/CD signifie que même les référentiels internes sont exposés à des risques.
Comment utiliser la SBOM et Supply Chain comme moyen de défense
Les outils SBOM et de chaîne d'approvisionnement peuvent fournir :
- Transparence des dépendances: suit les dépendances directes et transitives avec les métadonnées de version et de responsable.
- Vérification de la provenance: identifie les modifications inattendues apportées aux paquets ou les responsables inconnus.
- Surveillance des identifiants et des secrets: détecte les tentatives d'exfiltration ou les jetons utilisés de manière abusive.
- Informations comportementales: surveille l'accès aux ressources ou les modèles d'exécution inhabituels pendant les installations.
Bien que ce ne soit pas une solution miracle, la combinaison de la SBOM et d'une surveillance continue renforce les défenses contre les attaques de type ver.
OPSWAT et MetaDefender Software Supply ChainChain™
La technologie OPSWAT analyse le référentiel de code source et détecte le paquet npm sha1-hulud malveillant.
MetaDefender Software Supply Chain donne une image plus complète et détecte le paquet sha1-hulud compromis.
Metascan Multiscanning ajoute plusieurs niveaux de défense pour détecter les logiciels malveillants :
Mesures immédiates recommandées
- Faites tourner les identifiants: PAT GitHub, jetons npm, clés SSH, identifiants cloud ; activez l'authentification multifactorielle (MFA).
- Supprimer les paquets compromis: vider le cache npm, node_modules et épingler les versions connues pour être propres.
- Audit GitHub et CI/CD: recherchez les nouveaux dépôts, workflows et commits suspects.
- Renforcez la sécurité des pipelines: restreignez les scripts de cycle de vie, limitez l'accès au réseau sortant et réduisez au minimum la portée des jetons.
- Surveillance continue: traitez les dépendances et construisez des pipelines dans le cadre de la surface d'attaque critique.
Principaux enseignements
Les menaces pesant sur la chaîne d'approvisionnement sont indépendantes de l'écosystème
La propagation de Shai-Hulud 2.0 dans Maven/Java via le pont npm-to-Maven montre que les attaques de la chaîne logistique peuvent dépasser les frontières des langages et des écosystèmes. Même les projets qui n'utilisent pas directement npm peuvent être exposés si des outils de pontage automatisés sont utilisés.
L'hygiène des identifiants est fondamentale
Les jetons volés (GitHub, npm, cloud) permettent la propagation et l'accès à des environnements sensibles. Utilisez des jetons à durée de vie limitée et à portée restreinte, imposez l'authentification multifactorielle (MFA) et faites tourner les identifiants immédiatement après tout soupçon de compromission. Utilisez des outils automatisés de scan des secrets pour accélérer le processus.
Supply Chain holistique Supply Chain est obligatoire
Il ne suffit pas de se fier uniquement à l'analyse SCA statique ou au verrouillage des versions. Combinez la visibilité SBOM, l'analyse multicouche des logiciels malveillants et la protection des jetons/secrets pour réduire l'exposition dans tous les écosystèmes. Découvrez MetaDefender Software Supply Chain
Prêt à sécuriser votre chaîne logistique logicielle et à prévenir les cyberattaques grâce à des solutions sur mesure et parfaitement intégrées ?
