Le retour de Shai-Hulud révèle la fragilité de l'écosystème JavaScript : vol de secrets, runners GitHub détournés et saboteurs intégrés dans plus de 300 paquets npm infectés

La communauté JavaScript pensait avoir tiré les leçons de la première vague Shai-Hulud. Pourtant, fin novembre 2025, une nouvelle offensive frappe l’écosystème npm avec une sophistication inédite. Plus de 300 paquets infectés, des milliers de dépôts compromis, des jetons de cloud dérobés, des runners GitHub manipulés et, en bout de chaîne, une véritable démonstration de ce qu’une attaque supply-chain moderne peut provoquer.

Contexte : pourquoi ce type d’attaque est pertinent

L’écosystème npm est immense : des millions de paquets, de nombreuses dépendances transversales, et une grande part de confiance implicite envers les mainteneurs et les versions. Cette confiance est devenue une cible privilégiée pour les acteurs malveillants : en compromettant un paquet diffusé largement, ils peuvent infecter de nombreuses applications en aval, directement ou indirectement.

L’incident original nommé Shai‑Hulud (sans le « 1 ») avait déjà été documenté précédemment : une fonction d'auto-réplication et de propagation dans l’écosystème npm, avec vol de jetons, des insertions de workflows GitHub malveillants, etc. La nouvelle vague, Sha1-Hulud, reprend et amplifie ces techniques.

Le fait que la dernière campagne soit ciblée « par la chaîne d’approvisionnement logicielle » (software supply chain) la rend d’autant plus critique : ici, ce ne sont pas seulement des utilisateurs finaux ou des organisations spécifiques qui sont visés, mais potentiellement tous les projets reposant sur un des paquets compromis.

Une attaque qui rappelle la fragilité de l’écosystème JavaScript

L’écosystème npm est devenu un symbole de vitesse et d’efficacité, mais aussi de vulnérabilité. La multiplication des dépendances, les scripts d’installation automatiques, l’absence de vérification systématique du code publié : autant de portes ouvertes pour des campagnes malveillantes de plus en plus industrielles. Shai-Hulud, déjà connu pour une première vague particulièrement agressive, démontre une nouvelle fois à quelle vitesse une attaque supply-chain peut contaminer un environnement qui repose sur la confiance plus que sur le contrôle.

Dans cette seconde offensive, plus de 300 paquets ont été modifiés pour inclure du code malveillant. La contamination s’est ensuite propagée aux projets qui les utilisent, pour atteindre des dizaines de milliers de dépôts GitHub en quelques heures.

Selon HelixGuard, la campagne a vu ses paquets malveillants être publiés entre le 21 et le 23 novembre 2025.

De son côté, l'équipe de recherche sur les vulnérabilités de GitLab a elle aussi identifié une attaque active à grande échelle visant la chaîne d'approvisionnement, impliquant une variante destructrice de logiciel malveillant se propageant dans l'écosystème npm :

« Notre système de surveillance interne a détecté plusieurs paquets infectés contenant ce qui semble être une version évoluée du logiciel malveillant "Shai-Hulud". Les premières analyses montrent un comportement de propagation de type ver qui infecte automatiquement d'autres paquets gérés par les développeurs concernés. Plus grave encore, nous avons découvert que le logiciel malveillant contient un mécanisme de "commutateur d'homme mort" qui menace de détruire les données des utilisateurs si ses canaux de propagation et d'exfiltration sont coupés ».

Comment la contamination s’opère : anatomie d’un ver npm moderne

L’attaque repose sur une mécanique huilée, qui combine vol de secrets, propagation automatique et exploitation des plateformes de développement.

Un script d’installation comme porte d’entrée

Le cœur de l’attaque réside dans les scripts « postinstall » insérés dans les paquets infectés. Lorsqu’un développeur installe la dépendance, un fichier JavaScript obfusqué s’exécute automatiquement.
Ce script scanne l’environnement local à la recherche de secrets :

• jetons npm,
• clés GitHub (PATs),
• identifiants AWS/GCP/Azure,
• variables d’environnement sensibles,
• fichiers de configuration cloud.
  

Ces secrets permettent ensuite au malware de rebondir sur d’autres surfaces : création de dépôts GitHub, interactions avec les workflows, déploiement d’agents malveillants, etc.

Auto-réplication par infection des comptes npm compromis

Si le script trouve un jeton npm valide, il modifie automatiquement les paquets gérés par ce compte. Il insère le code malveillant dans la nouvelle version, puis publie le paquet mis à jour comme s’il s’agissait d’une release légitime. Ce mécanisme transforme l’attaque en ver : chaque compte compromis amplifie la propagation en infectant ses propres bibliothèques.

Manipulation des workflows GitHub pour persister

Nouvel élément inquiétant : le malware crée ou modifie des workflows GitHub Actions pour maintenir un accès permanent. Il installe un runner auto-hébergé portant un nom spécifique, ajoute des workflows capables d’exécuter des commandes à distance et crée parfois des dépôts publics pour exfiltrer les données dérobées.

Capacité destructive en cas d’échec

Lorsque le ver n’arrive pas à voler des secrets exploitables, il déclenche parfois un volet destructeur. Dans certains scénarios observés, il supprime le répertoire personnel de la machine ou efface des configurations essentielles, transformant une attaque de vol en attaque de sabotage.

GitLab résume l'attaque de cette manière :

[QUOTE=GitLab]Notre système de surveillance interne, qui analyse les registres de paquets open source à la recherche de paquets malveillants, a identifié plusieurs paquets npm infectés par un logiciel malveillant sophistiqué qui :

• Récupère les identifiants de GitHub, npm, AWS, GCP et Azure.
• Exfiltre les données volées vers des référentiels GitHub contrôlés par les attaquants.
• Se propagent en infectant automatiquement d'autres paquets appartenant aux victimes
• Contiennent une charge utile destructrice qui se déclenche si le logiciel malveillant perd l'accès à son infrastructure
  

Bien que nous avons confirmé plusieurs paquets infectés, le mécanisme de propagation de type ver signifie que de nombreux autres paquets sont susceptibles d'être compromis. L'enquête se...