Miasma : Comment un compte Red Hat volé a transformé la provenance npm en cheval de Troie

L’attaque qui a rendu les signaux de confiance peu fiables

La sécurité de la chaîne logistique logicielle a passé trois ans à converger vers un objectif unique : la provenance. Si l’on peut prouver cryptographiquement qu’un paquet a été construit à partir d’un dépôt connu, par un workflow connu, à un moment connu — on devrait être en sécurité. Le ver Miasma, qui a explosé dans le namespace npm @redhat-cloud-services le 1er juin 2026, a balayé cette hypothèse en une seule après-midi.

En compromettant le compte GitHub d’un employé Red Hat et en détournant le pipeline de publication approuvée OIDC — conçu précisément pour éliminer les secrets de longue durée —, les attaquants ont publié 96 versions malveillantes de paquets, toutes portant des signatures SLSA de provenance valides. Les paquets affichaient de vrais chiffres de téléchargement, un namespace de confiance, et des attestations cryptographiques de Sigstore. Pour tout scanner de sécurité automatisé, ils paraissaient parfaitement propres.

Cet incident n’est pas seulement un problème Red Hat. Il constitue une preuve de concept que l’architecture de confiance de la chaîne d’approvisionnement sur laquelle l’industrie s’est alignée — tokens OIDC à courte durée de vie, provenance SLSA, attestations Sigstore — peut être retournée contre elle-même dès qu’un seul compte humain est compromis.

Comment Miasma a weaponisé les signaux de confiance

1. Prise de contrôle de compte par spearphishing

L’analyse d’Aikido Security sur l’incident du 1er juin montre qu’un compte GitHub spécifique d’un employé Red Hat a été compromis, permettant aux attaquants de pousser des commits orphelins malveillants directement dans trois dépôts — RedHatInsights/frontend-components, RedHatInsights/javascript-clients et RedHatInsights/platform-frontend-ai-toolkit — en contournant entièrement la revue de code. La prise de contrôle du compte a rendu possibles deux vagues de publications malveillantes : l’une à 10h53 UTC et une seconde à 13h44 UTC, toutes deux le 1er juin 2026.

Le vecteur d’accès initial n’était pas un zero-day dans GitHub ou npm. C’était un humain. Cibler par spearphishing un seul développeur disposant d’un accès en écriture au dépôt suffit à déverrouiller l’intégralité de la chaîne de confiance CI/CD — car les pipelines modernes sont conçus pour faire confiance à l’identité de quiconque pousse le commit.

Miasma n’est pas apparu de nulle part. Wiz Research a retracé la lignée de l’attaque jusqu’à une campagne plus large qui a touché Bitwarden CLI le 22 avril, quatre paquets SAP le 29 avril, PyTorch Lightning le 30 avril, et le paquet DurableTask de Microsoft le 19 mai. Dès le 12 mai, le toolkit sous-jacent — surnommé « Mini Shai-Hulud » par le groupe d’acteurs menaçants TeamPCP — avait été publié en open source, permettant à des acteurs indépendants de l’adapter. Miasma est l’une de ces adaptations, remplaçant les références à la mythologie Dune par la mythologie grecque, et ajoutant de nouveaux collecteurs d’identifiants ciblant GCP et Azure.

2. Abus de GitHub Actions OIDC pour générer des attestations fiables

L’abus critique n’était pas une attaque en force — c’était de l’élégance. Le blog sécurité de Microsoft documente qu’une fois dans les dépôts Red Hat, les attaquants ont créé un workflow GitHub Actions ci.yaml avec des permissions id-token: write — la configuration standard pour la publication approuvée. Ce workflow se déclenchait « à chaque push sur n’importe quelle branche », exécutait un payload _index.js obfusqué, puis demandait un token d’identité OIDC à courte durée de vie au service de tokens de GitHub. Ce token était échangé avec l’endpoint de publication approuvée de npm pour publier des paquets dans le scope @redhat-cloud-services avec des attestations SLSA de provenance valides générées via les services Fulcio et Rekor de Sigstore.

Du point de vue du registre de paquets npm, la publication était impossible à distinguer d’une exécution CI/CD Red Hat légitime. La chaîne d’attestation était intacte. Le namespace était correct. L’ID du workflow correspondait. La provenance SLSA, que la communauté de sécurité a présentée comme l’antidote aux attaques de la chaîne d’approvisionnement, est devenue le mécanisme qui rendait les paquets malveillants plus convaincants — pas moins.

Surtout, Miasma générait un payload chiffré de manière unique pour chaque infection, contournant les règles de détection basées sur les hachages que les outils de sécurité utilisent généralement pour signaler les versions de paquets connues comme malveillantes.

3. Script preinstall pour la collecte d’identifiants

Le paquet malveillant incluait un hook preinstall — "preinstall": "node index.js" — qui se déclenche automatiquement lors de npm install, avant qu’un développeur n’ait la moindre opportunité d’inspecter ce qu’il a installé. Le dropper pesait 4,2 Mo et utilisait une obfuscation en couches : un grand tableau de codes de caractères reconstruit à l’exécution, décodé via une transformation de chiffrement César de type ROT, puis exécuté dynamiquement via eval(). Les étapes suivantes ajoutaient un chiffrement AES-128-GCM et une protection de tableau de chaînes Obfuscator.io, exécutant finalement un payload basé sur Bun.

La collecte d’identifiants était exhaustive. D’après l’analyse technique détaillée de Microsoft, le malware ciblait : les secrets GitHub Actions dont GITHUB_TOKEN et ACTIONS_RUNTIME_TOKEN ; les identifiants AWS IAM et Secrets Manager ; les tokens OAuth2 Azure IMDS et l’accès Key Vault ; les tokens de comptes de service GCP ; les tokens HashiCorp Vault ; les identifiants de comptes de service Kubernetes ; les tokens npm et PyPI ; les clés SSH ; les identifiants Docker ; les clés GPG ; les fichiers .env ; et les identifiants stockés dans les navigateurs. Tout développeur ou runner CI ayant exécuté npm install sur une version affectée a potentiellement exfiltré des identifiants sur l’ensemble des cloud auxquels il avait accès.

Ce que les équipes de sécurité doivent faire

1. Auditez immédiatement les scopes des tokens OIDC de votre CI/CD

La permission id-token: write est la clé de voûte de la publication approuvée — mais c’est aussi la surface d’attaque qu’a exploitée Miasma. Chaque workflow GitHub Actions de votre organisation portant cette permission doit être examiné. Le scope doit être limité à l’opération minimale requise : si un workflow publie sur npm, il ne devrait pas simultanément disposer des permissions contents: write ou packages: write. Appliquez des règles de protection de branche afin que les fichiers de workflow dans .github/workflows/ ne puissent être modifiés que par un ensemble restreint de mainteneurs avec revue obligatoire — et non par quiconque dispose d’un accès en push.

Wiz recommande d’implémenter des listes blanches de dépendances et la génération de SBOM afin que toute nouvelle version de paquet intégrée dans un build déclenche une alerte avant son exécution. L’attaque par hook preinstall fonctionne parce que npm install est traité comme une opération sûre et automatisée — supprimer cette hypothèse est le premier contrôle pratique.

2. Traitez la provenance comme un signal, pas comme une garantie

La provenance SLSA et les attestations Sigstore vous indiquent comment un paquet a été construit et depuis où — elles ne vous disent pas si le compte qui a déclenché le build était légitimement contrôlé par son propriétaire au moment du build. Les attestations de Miasma étaient cryptographiquement valides parce que le build s’est exécuté sur l’infrastructure GitHub en utilisant un compte légitime (même si piraté).

L’industrie doit superposer des signaux supplémentaires à la provenance : détection d’anomalies comportementales (un workflow qui n’a jamais publié auparavant et qui publie soudainement 32 versions de paquets en deux vagues est une anomalie), scoring de risque au niveau du compte (le compte GitHub a-t-il récemment été accédé depuis un emplacement inhabituel ?), et confiance limitée dans le temps (une attestation de provenance pour une version de paquet publiée 12 heures après la dernière version légitime devrait déclencher une revue humaine, pas une installation automatique). La provenance est une condition nécessaire à la confiance — pas une condition suffisante.

3. Imposez la revue des scripts preinstall dans votre politique npm

L’option --ignore-scripts de npm install empêche les hooks preinstall et postinstall de s’exécuter. Pour les pipelines CI de production qui n’ont pas besoin de scripts de cycle de vie, cet indicateur devrait être un défaut non négociable. Microsoft l’a explicitement recommandé dans ses conseils de remédiation Miasma. Dans les environnements d’entreprise, les politiques de paquets npm devraient signaler tout paquet qui introduit nouvellement un script preinstall dans une version mise à jour — un schéma qui n’a aucun cas d’usage bénin dans la plupart des dépendances de production.

Pour les équipes exécutant déjà des versions affectées, Microsoft recommande de faire pivoter immédiatement tous les identifiants exposés : tokens GitHub, identifiants cloud IAM (AWS, GCP, Azure), clés SSH, tokens npm et PyPI, comptes de service Kubernetes, et tokens HashiCorp Vault. L’exfiltration se produit silencieusement au moment de l’installation — considérez que tout système ayant exécuté une version affectée est entièrement compromis jusqu’à la rotation complète des identifiants.

Le paradoxe de la confiance : quand la provenance devient une arme

Miasma est la démonstration la plus claire à ce jour que l’architecture actuelle de sécurité de la chaîne d’approvisionnement a un point de défaillance unique : les comptes humains. La publication approuvée OIDC avait été conçue pour éliminer le risque de tokens npm à longue durée de vie volés — et elle a réussi. Miasma n’avait pas besoin d’un token à longue durée de vie. Il avait besoin d’un seul compte développeur compromis et de quinze minutes de temps d’exécution GitHub Actions.

La campagne d’attaque plus large derrière Miasma — couvrant Bitwarden, SAP, PyTorch et le paquet DurableTask de Microsoft au cours des six semaines précédant l’incident Red Hat — montre que ce n’est pas opportuniste. Les acteurs menaçants sondent systématiquement l’infrastructure de publication approuvée des principaux écosystèmes, identifiant les paquets à la plus forte amplification en aval (116 991 téléchargements hebdomadaires pour le seul scope Red Hat), et chronométrant les compromissions pour frapper les pipelines avant que les mainteneurs ne s’en aperçoivent.

La réponse politique doit rattraper son retard. La provenance SLSA de niveau 3 offre de solides garanties sur l’infrastructure de build — mais elle ne dit rien sur l’hygiène des comptes. La prochaine frontière est le SLSA de niveau 4 : des builds hermétiques et reproductibles qui découplent l’artefact de tout compte humain spécifique. Jusqu’à ce que cela devienne courant, la provenance est un signal que des attaquants sophistiqués ont appris à forger en remontant d’un niveau dans la chaîne de confiance. Les équipes de sécurité qui traitent un badge de provenance vert comme un paquet vérifié opèrent sur une hypothèse que Miasma a désormais invalidée.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Miasma Malware Targets npm Packages — The Hacker News
• Preinstall Persistence Inside Red Hat npm: Miasma Credential-Stealing Campaign — Microsoft Security Blog
• Miasma Supply Chain Attack Targeting Red Hat npm Packages — Wiz
• Red Hat npm Packages Compromised: Credential-Stealing Worm — Aikido Security