Miasma : 157 octets pour compromettre toute une chaîne npm

Introduction

En quelques dizaines d'heures, un ver baptisé Miasma a contraint GitHub à désactiver 73 dépôts appartenant aux organisations Microsoft, Azure, Azure-Samples et MicrosoftDocs. C'est l'escalade finale d'une campagne déclenchée discrètement le 3 juin 2026 par la compromission de dizaines de packages npm — et qui illustre, une fois de plus, la fragilité structurelle des chaînes d'approvisionnement logicielles modernes.

Une technique d'évasion inédite : Phantom Gyp

Ce qui distingue Miasma des attaques classiques sur l'écosystème npm n'est pas son ampleur, mais sa méthode. Oubliez les scripts preinstall et postinstall — les vecteurs habituels que les outils de sécurité surveillent depuis des années. Phantom Gyp s'appuie sur un mécanisme tout autre : le fichier binding.gyp.

Ce fichier de configuration, normalement utilisé pour compiler des modules natifs Node.js via node-gyp, ne figure pas dans les listes de contrôle standard des lifecycle scripts npm. Avec seulement 157 octets, les attaquants l'ont armé pour déclencher l'exécution de code arbitraire au moment d'un simple npm install, sans lever la moindre alerte dans la plupart des pipelines DevSecOps en place. Aucune CVE, aucun hook surveillé — juste un mécanisme de build légitime détourné.

Une propagation automatisée à grande vitesse

Miasma ne se contente pas de s'exécuter : il se reproduit. Une fois les tokens npm d'un mainteneur dérobés, le ver republie des versions malveillantes de tous les packages accessibles depuis ce compte, créant une réaction en chaîne. En moins de deux heures le 3 juin, 57 packages étaient touchés et plus de 286 versions corrompues avaient été publiées sur le registre npm.

Parmi les premières cibles figuraient des packages du namespace @redhat-cloud-services, mais aussi des SDKs à forte adoption comme @vapi-ai/server-sdk (plus de 408 000 téléchargements mensuels). Le malware exfiltre méthodiquement les tokens AWS, GCP, Azure, les credentials GitHub et npm, ainsi que les secrets HashiCorp Vault et Kubernetes — le tout transféré vers des dépôts GitHub contrôlés par les attaquants et utilisés comme boîtes aux lettres chiffrées.

C'est via un commit malveillant injecté dans le dépôt Azure/durabletask — à travers un compte contributeur préalablement compromis — que l'infection a atteint les organisations Microsoft, forçant GitHub à réagir le 6 juin en désactivant les 73 dépôts concernés.

Ce que cela change pour vos équipes techniques

L'attaque Miasma pose un problème fondamental que les équipes de développement et les RSSI ne peuvent plus ignorer : les contrôles de sécurité centrés sur les lifecycle scripts npm sont insuffisants. Un projet peut intégrer npm audit, des vérifications de signature via Sigstore, ou des attestations de provenance — et rester vulnérable si un vecteur d'exécution alternatif comme binding.gyp n'est pas dans le périmètre de surveillance.

Plusieurs actions concrètes s'imposent :

Auditer les binding.gyp dans les dépendances : leur présence n'est pas systématiquement malveillante, mais elle doit déclencher une revue systématique.
Restreindre les permissions des tokens npm et GitHub en CI/CD : un token compromis ne doit pas donner accès à l'ensemble du namespace d'une organisation.
Isoler les environnements d'installation : exécuter npm install dans un sandbox sans accès réseau sortant limite considérablement la capacité d'exfiltration.
Monitorer les nouvelles versions publiées sur les packages critiques de votre projet, pas seulement leurs vulnérabilités connues.

La supply chain logicielle, nouveau terrain de jeu offensif

Miasma n'est pas un incident isolé. Il s'inscrit dans une tendance lourde : les acteurs malveillants ont compris que les registres de packages publics constituent un maillon faible des organisations modernes. Toute équipe qui consomme des dépendances open source — c'est-à-dire pratiquement toutes — est potentiellement exposée.

Dans un contexte où NIS2 impose désormais aux entreprises européennes de démontrer une maîtrise de leur chaîne d'approvisionnement numérique, des incidents comme Miasma ne sont plus seulement des alertes techniques : ce sont des signaux de risque organisationnel à inscrire dans les plans de traitement des risques cyber.