Microsoft Threat Intelligence a révélé les détails d’une attaque de grande ampleur contre la chaîne d’approvisionnement npm, qui a touché plus de 400 paquets associés à des éditeurs apparemment non liés, notamment des paquets appartenant à des écosystèmes logiciels d’entreprise tels que keyv, flat-cache et cache-manager. Les versions malveillantes contenaient une variante du ver Mini Shai-Hulud, une charge utile JavaScript basée sur Bun et fortement obfusquée, conçue pour voler des identifiants et se propager automatiquement en republ iant des mises à jour malveillantes.
Cette attaque est particulièrement importante en raison de son mode opératoire : le logiciel ne se contente pas de voler les jetons présents sur le poste d’un développeur ou dans un environnement de build ; il exploite également ces jetons pour accéder à npm, GitHub, Amazon Web Services, Kubernetes et HashiCorp Vault, puis examine les ressources et les secrets autorisés par les identités volées. Selon l’analyse de Microsoft publiée le 4 août 2026, tout poste de travail ou agent de build ayant importé un paquet affecté et activé les scripts de cycle de vie npm doit être considéré comme compromis.
Exécution précoce dans les environnements de développement
Les versions affectées ajoutaient généralement un script preinstall qui exécutait un fichier nommé setup.mjs avant la fin de l’installation du paquet. Le fichier lançait un gros paquet Bun obfusqué, permettant l’exécution de la charge utile sur les appareils des développeurs et les nœuds de build avant le début des tests de l’application ou l’intervention de certains contrôles de sécurité classiques.
Le ver examine d’abord l’environnement afin de déterminer s’il s’exécute sur le poste d’un développeur ou dans le cadre d’une tâche CI/CD. Sur les postes de développeurs, il se détache afin de poursuivre son exécution en arrière-plan après la fin de l’installation, tandis qu’il reste associé à la tâche dans les environnements CI/CD pour exploiter les secrets du workflow, les identifiants de l’agent et les privilèges de publication via OpenID Connect. Il vérifie également qu’aucune autre instance n’est en cours d’exécution et s’arrête sur les systèmes utilisant la langue russe, selon les observations de Microsoft.
Vol d’identifiants et transformation en propagation
La charge utile commence par collecter les fichiers d’identifiants disponibles localement, les variables d’environnement, l’historique des commandes, les clés SSH et les outils cloud, ainsi que les données présentes dans la mémoire des agents GitHub Actions. Elle tente notamment d’obtenir un jeton GitHub CLI. Elle utilise ensuite les identifiants extraits pour appeler les interfaces des services npm, GitHub, AWS, Kubernetes et HashiCorp Vault, vérifier les autorisations et collecter d’autres secrets.
Les résultats sont chiffrés au format JSON compressé à l’aide d’AES-256-GCM, la clé AES étant chiffrée au moyen de RSA-OAEP-SHA256, puis envoyés vers un point de terminaison HTTPS contrôlé par l’attaquant. GitHub est utilisé comme canal de repli pour l’exfiltration des données lorsque le canal principal est indisponible. Microsoft a indiqué que l’infrastructure active au moment de l’analyse renvoyait le domaine npm-cache[.]com, tandis que des candidats antérieurs tels que pypi-get[.]com et js-mirror[.]com étaient également apparus.
Quant au principal mécanisme de propagation, il examine les jetons npm afin de déterminer s’ils permettent l’écriture dans les paquets ou le contournement de l’authentification à deux facteurs, puis télécharge le dernier fichier tarball de chaque paquet accessible à l’identité compromise. Le ver se copie dans l’archive, ajoute le chargeur d’installation et le script de cycle de vie, incrémente le numéro de version de correctif, puis republie le paquet. Cela explique l’apparition de versions malveillantes semblant être de simples mises à jour patch, sans commit, demande de fusion ni étiquette de version correspondante dans le dépôt source.
Voies supplémentaires via GitHub
La charge utile vérifie les portées des jetons GitHub, dénombre les dépôts accessibles en écriture et recherche des dépôts dans lesquels les workflows pourraient révéler d’autres secrets. Elle comprend également une voie ciblant les paquets npm publiés via GitHub Actions en tant qu’éditeurs de confiance, ce qui peut conférer aux versions publiées une provenance valide, puisque la publication provient d’une identité de workflow légitime.
Le ver peut également injecter des fichiers de configuration dans les branches des dépôts, notamment des chemins associés à Claude et Visual Studio Code tels que .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json et .vscode/setup.mjs. Ces modifications fournissent une voie d’infection secondaire susceptible de relancer la charge utile lors de l’utilisation de Claude ou de Visual Studio Code, même après la fin de l’installation du paquet d’origine. Microsoft a indiqué que l’une des voies de repli de GitHub tentait également d’installer un composant de surveillance des jetons, avec un gestionnaire destructeur conditionnel lors de l’annulation du jeton surveillé.
Que recommande Microsoft ?
Microsoft recommande de mettre à jour npm CLI vers la version 12 et d’utiliser la fonctionnalité min-release-age, ainsi que d’examiner les arbres de dépendances, les fichiers de verrouillage, les dépôts d’artefacts et les caches CI à la recherche des cinq versions affectées, y compris les références indirectes. Il convient également d’épingler des versions connues comme sûres et de vider les caches npm et yarn sur les appareils des développeurs et les hôtes de build, en particulier lorsque les archives compromises ont été introduites dans un cache CI partagé.
Si un système de build ou un poste de travail a importé une version affectée, les identifiants et les secrets doivent être renouvelés depuis un appareil propre, car l’exécution de la deuxième étape peut exposer les jetons et compromettre l’intégrité du processus de build. Les recommandations comprennent également l’activation de la protection cloud de Microsoft Defender Antivirus, des mesures de Microsoft Defender for Endpoint et de Microsoft Defender for Containers, ainsi que des workflows d’investigation de Microsoft Defender XDR sur les actifs de développement et de CI.
La réponse ne doit pas se limiter à l’examen des appareils. Les entités qui produisent des artefacts logiciels doivent revoir le durcissement du processus de publication, les portées des jetons, les approbations des workflows, les environnements protégés, la preuve de provenance des versions et les mécanismes de détection des publications automatisées inhabituelles, car l’incident est cohérent avec un abus des pipelines CI/CD via les privilèges GitHub Actions OIDC. Après la remédiation, il convient de reconstruire les projets à partir d’une base de référence fiable, de vérifier l’absence d’empreintes compromises dans les caches et les dépôts d’artefacts, et d’examiner les mesures à la recherche de traces Node.js telles que Math_Symbol.js, Math_init.js ou des fichiers portant des noms similaires à math_<guid>.js, tout en reconstruisant les images de base et les agents de build modulaires.