Attaque de la chaîne d’approvisionnement Miasma : du code malveillant découvert dans les packages npm @redhat-cloud-services

Le 1er juin 2026, des chercheurs ont identifié du code malveillant intégré dans au moins 32 versions de packages publiées sous l’espace de noms npm @redhat-cloud-services, un ensemble de composants frontend et de clients API qui alimentent la Red Hat Hybrid Cloud Console. Les versions compromises contiennent un script preinstall qui exécute une charge utile obfusquée dès l’installation d’un package, collecte les identifiants des développeurs et du cloud, et tente de se propager à d’autres packages que la victime peut publier. Les packages concernés totalisent environ 80 000 téléchargements par semaine, ce qui étend largement l’impact au-delà des pipelines de Red Hat.

La campagne a été baptisée Miasma. Sa charge utile est une variante légèrement remaniée du ver (Mini) Shai-Hulud, publié en open source par TeamPCP plus tôt cette année. Si vous avez installé un package @redhat-cloud-services, ou créé un projet qui en dépend, considérez qu’il s’agit d’un incident en cours et partez du principe que tous les secrets présents sur les machines concernées sont exposés.

En bref

• Quoi : Code malveillant (ver qui se propage lui-même et voleur d’identifiants) intégré à des versions npm publiées.

• Espace de noms : @redhat-cloud-services (composants frontend et clients API de la Red Hat Hybrid Cloud Console).

• Étendue : Au moins 32 versions de packages dans cet espace de noms, pour environ 80 000 téléchargements hebdomadaires au total. Publiées en deux vagues.

• CVE : Aucun identifiant attribué. Suivi dans les avis de sécurité Snyk. Snyk attribue à l’avis principal une note de 9,3 (Critique, CVSS v4.0), avec une maturité d’exploitation « Attacked ».

• Cause première : Le compte GitHub d’un employé de Red Hat a été compromis et utilisé pour pousser des commits orphelins malveillants qui demandaient un jeton OIDC de publication npm et publiaient des packages avec une provenance SLSA valide.

• Statut : La plupart des versions malveillantes avaient été révoquées de npm quelques heures après la divulgation ; quelques-unes étaient encore disponibles pendant la poursuite de l’analyse. L’enquête est en cours.

• Mesures à prendre : Épinglez vos dépendances sur des versions non concernées, réinstallez avec les scripts désactivés et renouvelez tous les identifiants accessibles depuis une station de travail ou un exécuteur CI affecté.

Que s’est-il passé ?

Les packages de l’espace de noms @redhat-cloud-services sont des dépendances de compilation de la Hybrid Cloud Console : composants React partagés (@redhat-cloud-services/frontend-components, frontend-components-utilities, frontend-components-notifications), clients API générés (rbac-client, host-inventory-client, compliance-client et une vingtaine d’autres) et outils connexes. Plusieurs d’entre eux génèrent à eux seuls un trafic important. Pour vérifier rapidement l’ampleur signalée, l’API de téléchargements npm indique que les packages les plus populaires, comme @redhat-cloud-services/types, enregistrent plusieurs dizaines de milliers de téléchargements par semaine :

1# https://api.npmjs.org/downloads/point/last-week/@redhat-cloud-services%2Ftypes
2curl -s "https://api.npmjs.org/downloads/point/last-week/@redhat-cloud-services%2Ftypes"
3# {"downloads":15060, ... }

En additionnant les téléchargements de la dernière semaine complète (du 25 au 31 mai 2026) pour les packages concernés, on obtient environ 79 000 téléchargements, ce qui correspond au chiffre d’environ 80 000 cité pour cet incident. Les modifications non autorisées ont été identifiées pour la première fois le 1er juin 2026.

Les versions malveillantes ont été publiées en deux vagues le 1er juin. Lorsque les avis de sécurité ont été diffusés, npm avait révoqué la plupart des versions concernées, mais quelques-unes étaient encore disponibles pendant l’analyse.

Détails techniques

Le déclencheur à l’installation

Chaque version compromise ajoute un hook exécuté à l’installation. npm exécute automatiquement les scripts preinstall pendant npm install, avant l’exécution de votre propre code. Il suffit donc de résoudre la dépendance pour déclencher la charge utile :

1{
2  "scripts": {
3    "preinstall": "node index.js"
4  }
5}

Le fichier index.js qu’il exécute est un fichier JavaScript inhabituellement volumineux et fortement obfusqué. L’auteur s’est appuyé sur eval() et le décodage de chaînes basé sur ROT pour dissimuler la logique, une technique déjà observée dans d’anciennes variantes de Shai-Hulud. Une fois décodée, la charge utile se révèle être un collecteur d’identifiants et un ver en plusieurs étapes.

Fonctionnement de la charge utile

Le cœur fonctionnel correspond au framework (Mini) Shai-Hulud, même si les références à la mythologie grecque ont remplacé les éléments cosmétiques inspirés de Dune (comme l’utilisation de spartan). Les dépôts créés par les attaquants portent la description Miasma: The Spreading Blight, un indice utile pour les repérer.

Lorsqu’elle s’exécute, la charge utile :

• Collecte les secrets et les identifiants de l’environnement local et du contexte CI : variables d’environnement, jetons ~/.npmrc, clés SSH, jetons GitHub et secrets CI/CD.

• Recense les identités cloud. La différence notable de cette variante est l’ajout de deux collecteurs pour GCP et Azure, qui recensent toutes les identités que l’hôte infecté peut assumer, et pas seulement les secrets statiques. Les variantes précédentes visaient surtout à récupérer les identifiants ; celle-ci cherche à cartographier et à atteindre le plan de contrôle cloud lui-même.

• Se propage d’elle-même. Elle interroge le registre pour trouver d’autres packages que l’identité compromise peut publier, puis les republie avec la même charge utile. C’est ainsi qu’un seul mainteneur compromis devient un ver.

Cause première : compte compromis, provenance valide

C’est un point qui mérite qu’on s’y attarde. Le code malveillant ne s’est pas introduit via un typosquat ou une dépendance transitive empoisonnée. Les éléments disponibles indiquent que le compte GitHub d’un employé de Red Hat a été compromis et utilisé pour pousser des commits orphelins malveillants directement dans deux dépôts RedHatInsights, en contournant la revue de code.

Ces commits ont ajouté un workflow GitHub Actions minimal qui :

1. Se déclenchait lors d’un push sur n’importe quelle branche.

2. Demandait un jeton d’identité OIDC GitHub via id-token: write.

3. Exécutait une charge utile obfusquée (_index.js) qui publiait les packages sur npm.

La publication ayant eu lieu dans le contexte Actions d’un dépôt légitime, les versions obtenues comportaient des attestations de provenance SLSA valides. La provenance était techniquement correcte : le package avait bien été compilé par le workflow de ce dépôt. Mais elle ne pouvait pas indiquer que le workflow lui-même n’était pas autorisé. C’est la même faille que TeamPCP a exploitée contre TanStack quelques semaines plus tôt : une provenance falsifiée mais valide a permis à des packages malveillants de passer des vérifications superficielles. Cela rappelle également le vol de jetons côté exécuteur observé lors de la compromission de l’action GitHub Trivy. La vérification de la provenance est nécessaire, mais ne suffit pas à elle seule.

Analyse de l’impact

Les chiffres directs de téléchargement sous-estiment l’exposition réelle. Il s’agit de dépendances de compilation d’une console d’entreprise : la plupart des installations ont donc lieu sur des stations de travail de développeurs et des exécuteurs CI, précisément les environnements qui disposent du plus grand nombre d’identifiants cloud à longue durée de vie, de jetons de registre et de jetons d’accès personnels GitHub (PAT). Le comportement du ver amplifie le risque : un seul développeur qui installe une version concernée et dispose des droits de publication sur d’autres packages peut déclencher la vague suivante.

Vous êtes potentiellement concerné si, depuis la première publication malveillante le 1er juin 2026, l’une des opérations suivantes a été exécutée :

• Un npm install / npm ci qui a résolu une version concernée de @redhat-cloud-services sur une station de travail ou un exécuteur CI.

• Une compilation dans un environnement cloud où l’exécuteur disposait d’identités GCP, AWS ou Azure, compte tenu des nouveaux collecteurs d’identités cloud.

Aucune configuration particulière de votre côté n’est nécessaire pour que l’exploitation fonctionne. Le hook preinstall s’exécute par défaut. Il suffit d’avoir installé une version concernée.

Détection

1. Recherchez les versions concernées dans vos fichiers de verrouillage. Recherchez l’espace de noms dans vos fichiers package-lock.json / pnpm-lock.yaml / yarn.lock :

1grep -r "@redhat-cloud-services" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

Comparez les versions résolues aux avis Snyk répertoriés dans la section Références. L’avis principal de Snyk signale @redhat-cloud-services/frontend-components pour les versions <=7.7.2 ; les versions limites varient selon le package, consultez donc chaque avis.

2. Effectuez une analyse avec Snyk. La base de données Snyk contient déjà des avis sur les versions malveillantes ; un test standard les détecte donc :

1snyk test --file=package-lock.json

Pour les organisations, la découverte des ressources et la hiérarchisation des risques vous aident à trouver chaque projet et exécuteur ayant récupéré une version concernée, puis à prioriser les mesures correctives selon le niveau d’exposition réel des identifiants dans chaque environnement, plutôt que de courir après chaque installation.

3. Recherchez les signes de compromission. Même après la suppression du package, la charge utile a peut-être déjà été exécutée. Recherchez :

• De nouveaux dépôts inattendus dans votre organisation GitHub, en particulier ceux portant la description Miasma: The Spreading Blight.

• Des workflows GitHub Actions non reconnus, notamment des workflows minimalistes qui demandent id-token: write et se déclenchent lors d’un push sur n’importe quelle branche.

• Des jetons d’accès personnels, des clés de déploiement ou des jetons npm récemment créés que vous n’avez pas générés.

• Des accès anormaux aux métadonnées d’identité GCP et Azure depuis les exécuteurs de compilation.

Mesures correctives

L’ordre des opérations est important. Cette famille de logiciels malveillants étant connue pour installer des mécanismes de persistance et, dans certaines variantes, des déclencheurs destructeurs, nettoyez la machine avant de révoquer les jetons qu’elle surveille.

1. Cessez d’installer les versions malveillantes. Épinglez ou remplacez vos dépendances par des versions fiables, ou supprimez temporairement les packages concernés, puis vérifiez que votre fichier de verrouillage ne résout plus de version signalée.

2. Réinstallez avec les scripts désactivés. Lors de la reconstruction d’une arborescence potentiellement affectée, bloquez les scripts d’installation afin qu’une version malveillante qui serait encore présente ne puisse pas être exécutée à nouveau :

1rm -rf node_modules
2npm install --ignore-scripts

Vous pouvez définir ce paramètre par défaut pour un environnement :

1npm config set ignore-scripts true

(Réactivez-les uniquement pour les packages qui nécessitent réellement des étapes de compilation.)

3. Supprimez les mécanismes de persistance. Auditez et supprimez tous les hooks installés par l’attaquant avant de toucher aux identifiants : configuration des éditeurs et des agents, comme .claude/settings.json et .vscode/tasks.json.

4. Renouvelez tous les identifiants accessibles. Partez du principe que tous les secrets accessibles depuis une machine concernée sont exposés, puis renouvelez-les par ordre de priorité : jetons npm, PAT GitHub et clés SSH, puis identifiants cloud. Compte tenu des nouveaux collecteurs, accordez une attention particulière aux identités cloud comme GCP, AWS et Azure, y compris aux rôles qu’un exécuteur CI pourrait assumer, et pas seulement aux clés statiques.

5. Nettoyez GitHub. Supprimez les dépôts et workflows non autorisés, examinez les exécutions récentes d’Actions à la recherche du schéma de publication OIDC décrit ci-dessus, et vérifiez qu’aucun package inattendu n’a été publié depuis vos comptes.

6. Renforcez le pipeline. À l’avenir : imposez une revue des branches protégées pour empêcher la publication de commits orphelins, limitez la confiance OIDC à des branches et workflows spécifiques plutôt qu’à des dépôts entiers, exigez l’authentification à deux facteurs avec protection de la publication sur npm, et associez la vérification de la provenance à des contrôles comportementaux au lieu de vous fier uniquement aux attestations. L’autorisation des dépendances, la génération de SBOM et un délai d’attente après la publication avant l’adoption de nouvelles versions réduisent tous la fenêtre exploitée par ce type d’attaque. Les ressources Snyk 10 bonnes pratiques de sécurité npm et 8 conseils pour sécuriser votre pipeline CI/CD abordent les autres mesures.

Chronologie

• 1er juin 2026 : Première vague de versions malveillantes publiée dans l’espace de noms @redhat-cloud-services.

• 1er juin 2026 (vers 13 h UTC) : Divulgation publique de la compromission ; la plupart des versions malveillantes sont révoquées, deux restent disponibles.

• 1er juin 2026 (vers 14 h UTC) : Publication de la cause première : compte d’employé compromis, packages publiés via OIDC avec une provenance SLSA valide.

• 1er juin 2026 (vers 14 h 20–15 h UTC) : Identification et prise en compte d’une deuxième vague de commits malveillants, ainsi que de détails sur les nouveaux collecteurs d’identités GCP/Azure de la charge utile.

• 2 juin 2026 : Ajout des versions compromises découvertes récemment aux packages déjà concernés.

• En cours : Les avis Snyk concernant les packages affectés sont disponibles. L’enquête se poursuit.