Red Hat NPM : l’attaque supply chain Miasma qui vole vos credentials cloud

Le 1er juin 2026, une attaque d’une sophistication rare a compromis 32 packages npm publiés sous le namespace @redhat-cloud-services. Le malware, baptisé « Miasma », a volé les identifiants GitHub, AWS, Azure et GCP de milliers de développeurs en exploitant une faille dans la chaîne d’approvisionnement logicielle de Red Hat.

Comment l’attaque s’est produite

Le 1er juin 2026, entre 13h00 et 13h01 UTC, un attaquant a publié des versions malveillantes de 32 packages npm sous le scope @redhat-cloud-services. Ces packages sont des composants frontend et des clients API qui alimentent la Red Hat Hybrid Cloud Console. L’ensemble du processus a duré 72 secondes, ce qui indique une automatisation poussée.

La faille initiale : un compte GitHub employé compromis

Selon les analyses de Wiz Research et de Microsoft Threat Intelligence, l’attaquant a compromis le compte GitHub d’un employé Red Hat. Avec ce compte, il a pushé des commits malveillants orphelins directement dans deux repositories RedHatInsights/javascript-clients, en court-circuitant le processus de code review.

Les commits ajoutaient un workflow GitHub Actions minimal qui :

• Se déclenchait sur un push vers n’importe quelle branche (pas uniquement main)
• Demandait un token OIDC GitHub pour npm via id-token: write
• Exécutait un payload obfusqué (_index.js) qui publiait les packages sur npm avec des attestations SLSA valides

C’est le même schéma que l’attaque contre TanStack quelques semaines plus tôt : la provenance SLSA est techniquement correcte (le package a bien été construit par le workflow du repository), mais le workflow lui-même était compromis. La confiance dans la chaîne de supply chain est érodée.

Le malware « Miasma » : ce qu’il fait concrètement

Chaque package compromis contenait un script preinstall qui s’exécute automatiquement lors d’un npm install, avant même que le code du package ne soit importé. Ce script invoquait un fichier index.js obfusqué de 4,29 Mo, qui fonctionnait comme un collecteur de credentials multi-étapes.

Propagation automatique : un ver dans la supply chain

La caractéristique la plus dangereuse de Miasma est sa capacité à se propager automatiquement. Une fois installé sur la machine d’un développeur, le malware :

• Interroge le registre npm pour identifier les autres packages que l’identité compromise peut publier
• Republie ces packages avec le même payload, via l’échange de token OIDC
• Crée des repositories GitHub inattendus contenant les credentials volés
• Peut injecter des workflows malveillants dans les repositories non protégés

Ox Security a identifié plus de 210 repositories GitHub contenant des credentials volés, ce qui suggère qu’au moins autant de développeurs ont été infectés après avoir installé une version malveillante d’un package @redhat-cloud-services.

Le lien avec Shai-Hulud et TeamPCP

Miasma est une variante du malware (Mini) Shai-Hulud, open-sourcé par le groupe TeamPCP plus tôt cette année. TeamPCP avait lancé un « challenge » invitant les acteurs malveillants à utiliser leur code dans des attaques supply chain. Miasma reprend le même code avec des modifications cosmétiques :

• Le marqueur « Miasma: The Spreading Blight » remplace les références à l’univers de Dune
• Des références à la mythologie grecque (« spartan ») remplacent les références originales
• La logique de vol de credentials et de propagation est identique
• Nouveauté : des collecteurs spécifiques pour les identités cloud GCP et Azure, qui énumèrent toutes les identités accessibles depuis la machine infectée

Cette attaque s’inscrit dans une série d’incidents similaires : TrapDoor qui ciblait npm, PyPI et Crates.io en mai 2026, et l’attaque contre TanStack quelques semaines avant Miasma. Le schéma se répète : compromission de compte mainteneur, injection via CI/CD, publication avec provenance valide.

Pourquoi cette attaque est particulièrement inquiétante

Trois éléments rendent Miasma plus dangereux que les attaques supply chain classiques :

Les entreprises et les développeurs doivent agir maintenant

Si votre organisation utilise des packages @redhat-cloud-services, ou si vos projets dépendent de ces packages en dépendance transitive, voici les actions prioritaires :

La leçon : la confiance dans la supply chain logicielle est fragile

Miasma démontre trois faiblesses structurelles de l’écosystème npm et de la supply chain logicielle moderne :

• Les scripts preinstall sont exécutés par défaut. Un simple npm install suffit à exécuter du code malveillant, sans interaction de l’utilisateur. npm n’a toujours pas résolu ce problème fondamental
• La provenance SLSA n’est pas suffisante. Une attestation valide prouve que le package a été construit par le workflow du repository, mais pas que le workflow lui-même est légitime. C’est le même gap exploité par TeamPCP contre TanStack
• La compromission d’un seul compte suffit. Un compte GitHub employé, un token OIDC, et toute la chaîne est compromise. L’authentification à deux facteurs ne protège pas contre le vol de session ou la compromission de token

Pour les DSI et les équipes de sécurité, le message est clair : la supply chain logicielle n’est pas seulement un problème technique. C’est un risque business qui nécessite une approche holistique : gestion des identités développeurs, audit des workflows CI/CD, pinning des versions de dépendances, et monitoring continu des publications npm.

Comme l’a montré Snyk dans son analyse détaillée, la plupart des organisations ne détectent pas ce type d’attaque avant qu’elle ne soit rendue publique. La question n’est pas de savoir si votre supply chain est vulnérable, mais quand elle sera testée.

---

Sources : Wiz Research, Microsoft Threat Intelligence, Snyk, Ox Security.