Le 1er juin 2026, 32 paquets appartenant au scope @redhat-cloud-services sur le registre npm ont été compromis par un ver voleur d'identifiants. Ces paquets totalisaient collectivement 116 991 téléchargements hebdomadaires au moment de l'incident, ce qui représente une exposition potentielle considérable pour les équipes de développement qui les intégraient dans leurs pipelines de production.
L'attaque s'est déroulée en deux temps distincts, documentés avec précision par les chercheurs de Wiz Research. La première vague a débuté à 10h53 UTC : des commits malveillants ont été poussés sur trois dépôts RedHatInsights. La deuxième vague a suivi entre 13h44 et 13h46 UTC, avec des commits additionnels sur les mêmes dépôts. Moins de trois heures séparent les deux vagues. Ce rythme suggère un acteur disposant d'un accès stable et d'une automatisation préparée en amont, pas une intrusion opportuniste.
Au total, 96 versions compromises ont été publiées, réparties sur les 32 paquets du namespace. Parmi les paquets affectés figuraient des composants activement utilisés dans les environnements Red Hat : @redhat-cloud-services/frontend-components, @redhat-cloud-services/chrome, @redhat-cloud-services/types, ainsi que 29 autres paquets du même espace de nommage, comme le détaille OX Security. À 13h UTC, la majorité des versions malveillantes avait été révoquée par npm. Deux versions restaient accessibles au moment de la publication des premières analyses.
Le vecteur d'entrée initial est tracé jusqu'au compte GitHub d'un employé Red Hat compromis, selon The Register. Ce n'est pas un token npm qui a été volé directement, c'est l'ensemble du pipeline CI/CD qui a été détourné.
Mettons cela en contexte. Le workflow GitHub Actions malveillant disposait des permissions id-token: write et contents: read, et se déclenchait sur tout push de branche, grâce à la directive on: push: branches: ['*']. Ce paramétrage, courant dans les projets open source actifs, permettait à l'attaquant de déclencher l'exécution du workflow sur n'importe quelle branche, sans restriction. Le workflow exécutait ensuite un payload obfusqué hébergé dans un fichier nommé _index.js, qui publiait les paquets npm corrompus sur le registre public.
La publication passait par le mécanisme OIDC, OpenID Connect, de GitHub Actions, qui permet à un workflow d'obtenir un jeton d'identité court-durée signé par GitHub, sans qu'aucun secret statique ne soit stocké dans le dépôt. En apparence, c'est une bonne pratique de sécurité. En pratique, si le workflow lui-même est compromis, ce mécanisme devient le vecteur de publication légitime d'un contenu malveillant. Les paquets ont même été publiés avec des attestations SLSA valides, contournant ainsi les contrôles de provenance que de nombreuses équipes considèrent comme une garantie d'intégrité.
Le malware déployé dans cette attaque se nomme Miasma. Il s'auto-identifie dans son code comme "Shai-Hulud: The Third Coming" et constitue une nouvelle variante du ver Shai-Hulud, dont le code source a été rendu public par le groupe TeamPCP. Semgrep établit clairement la filiation : l'attaque contre les paquets Red Hat suit une attaque précédente contre Tanstack, elle aussi attribuée aux mêmes techniques, elle aussi produisant des attestations SLSA valides à partir d'un contenu malveillant.
Ce point mérite attention. Les attestations SLSA, Supply Chain Levels for Software Artifacts, sont précisément conçues pour garantir que ce qui est publié correspond à ce qui a été compilé depuis un code source vérifié. Quand un workflow CI/CD légitime est lui-même l'instrument de la compromission, la chaîne de confiance cryptographique ne protège plus rien : elle certifie simplement que le malware a bien été produit par le processus de build attendu.
Selon Aikido Dev, les modifications apportées dans Miasma par rapport à la version originale de Shai-Hulud sont principalement cosmétiques : les références à l'univers Dune ont été remplacées par des thèmes de mythologie grecque, le terme "spartan" apparaît dans le code, mais les fonctionnalités et le mode opératoire restent substantiellement identiques. Cela soulève une question d'attribution que les analystes traitent avec prudence : TeamPCP ayant publié les détails techniques et le code de Mini Shai-Hulud, n'importe quel acteur suffisamment motivé peut répliquer ces techniques. Les similitudes observées doivent être lues comme une convergence de tactiques, techniques et procédures, pas comme une preuve formelle d'attribution au groupe d'origine.
La portée de la collecte réalisée par Miasma dépasse ce que l'on observe habituellement dans les stealers orientés navigateur ou les campagnes de phishing ciblées. Ce ver est conçu pour aspirer l'intégralité de la surface d'identité d'un environnement de développement ou CI/CD.
Concrètement, The Register documente la liste suivante de cibles : les tokens GitHub (GITHUB_TOKEN et ACTIONS_RUNTIME_TOKEN), les clés AWS et tokens de session associés, les identifiants GCP sous leurs deux formes principales, Application Default Credentials et comptes de service, les identifiants Azure couvrant les principaux de service et les identités managées, les tokens HashiCorp Vault, les tokens Kubernetes et les fichiers kubeconfig, les tokens npm et PyPI, les clés SSH privées, les identifiants de registres Docker, les clés GPG, et l'intégralité des fichiers .env présents sur le système de fichiers. Wiz Research précise que les collecteurs GCP et Azure de Miasma sont plus avancés que dans la version originale : ils sont capables de collecter toutes les identités auxquelles la machine infectée a accès, pas seulement les identifiants configurés explicitement.
Un développeur dont la machine ou le runner CI exécute un paquet affecté expose donc simultanément ses accès personnels, les secrets de son organisation, et potentiellement les identifiants de ses fournisseurs cloud. Une seule exécution suffit. Aucune persistance n'est nécessaire pour que les dégâts soient réels.
Selon le rapport ENISA sur les menaces de chaîne d'approvisionnement publié en 2024, 62 % des attaques de ce type ciblent des fournisseurs de confiance pour atteindre leurs clients en aval. L'incident Red Hat en est une illustration directe : ce ne sont pas les systèmes de Red Hat en tant qu'entreprise qui ont été compromis, c'est le compte GitHub d'un employé, suffisant pour infecter des dizaines de milliers d'environnements de développement à travers le monde via des paquets considérés comme fiables.
En novembre 2018, le mainteneur du paquet npm event-stream, alors téléchargé deux millions de fois par semaine, a transmis le contrôle du projet à un inconnu. Ce nouvel ayant droit a injecté du code malveillant ciblant spécifiquement les portefeuilles de cryptomonnaies Copay et BitPay. L'attaque n'a été détectée que cinq semaines après son déploiement, ce qui laisse imaginer le volume de machines ayant exécuté le code corrompu avant que l'alerte ne soit donnée.
Ce cas a posé une question que l'industrie n'a pas encore tranchée de façon satisfaisante : à partir de quel moment fait-on confiance à un mainteneur, et qui vérifie que cette confiance reste justifiée dans le temps ? Le registre npm héberge aujourd'hui plus de 3,8 millions de paquets. La grande majorité sont maintenus par des individus ou de petites équipes sans processus de sécurité formalisé.
En mars 2024, une backdoor a été découverte dans XZ Utils, un utilitaire de compression présent dans de nombreuses distributions Linux. L'acteur à l'origine de l'attaque, opérant sous le pseudonyme "Jia Tan", avait passé deux ans à contribuer légitimement au projet avant d'injecter le code malveillant dans la chaîne de build, de manière à ce qu'il soit inclus dans les binaires distribués mais absent du code source visible dans le dépôt. La découverte doit beaucoup au hasard : c'est un ingénieur de Microsoft qui a remarqué une anomalie de performance dans SSH sur une installation Debian lors de tests personnels.
XZ Utils illustre la patience dont certains acteurs sont capables. Deux ans de contributions bénévoles, crédibles, pour accéder à un point d'injection stratégique. L'attaque contre les paquets Red Hat est différente dans son exécution, elle est rapide, automatisée, mais elle partage le même principe fondateur : exploiter la confiance que les développeurs accordent aux sources qu'ils intègrent sans examen systématique.
SolarWinds, en décembre 2020, avait déjà démontré l'ampleur possible de ces compromissions : environ 18 000 organisations, dont des agences gouvernementales américaines, avaient installé la mise à jour malveillante d'Orion avant que l'incident ne soit détecté. Quand le build process lui-même est corrompu, la mise à jour légitime devient le vecteur de livraison.
Red Hat a confirmé que la compromission était limitée au pipeline de publication npm et à un compte GitHub individuel. Aucune compromission des systèmes internes. Du moins, pas encore, et c'est précisément ce type de déclaration que votre équipe de sécurité devrait accueillir avec scepticisme méthodique, pas par défiance envers Red Hat, mais parce que la visibilité sur les mouvements latéraux post-compromission prend du temps à établir.
Les paquets affectés appartiennent à la couche frontend des interfaces de gestion Red Hat Cloud Services. Ils sont utilisés dans des environnements qui gèrent des charges de travail OpenShift, des abonnements Red Hat Hybrid Cloud, et des tableaux de bord d'administration. Les développeurs qui les intègrent travaillent fréquemment dans des environnements disposant d'accès cloud à fort impact. C'est précisément ce profil que Miasma cherche à exploiter.
La rapidité avec laquelle npm a agi, révocation de la majorité des versions malveillantes dans les deux à trois heures suivant la première vague, est notable. Elle ne change cependant pas grand-chose pour les machines qui ont exécuté les paquets pendant cette fenêtre. Dans un pipeline CI/CD qui tourne toutes les heures, trois heures représentent plusieurs dizaines d'exécutions potentiellement compromises.
La surface d'attaque exposée par ce type d'incident dépasse largement les systèmes directement concernés. Chaque organisation qui utilise ces paquets dans son pipeline devient un maillon potentiellement compromis, et donc un vecteur possible vers ses propres clients ou partenaires. La chaîne de confiance se fragmente à chaque niveau.
Si votre organisation développe des applications en JavaScript ou TypeScript, gère des environnements cloud hybrides, ou utilise des outils Red Hat dans ses pipelines de livraison, cet incident vous concerne directement. Mais même si aucun des 32 paquets affectés n'apparaît dans vos dépendances immédiates, la leçon structurelle s'applique à votre posture de sécurité.
Les dépendances transitives, les paquets que vos paquets installent, et que leurs paquets installent à leur tour, constituent une zone aveugle pour la plupart des équipes. Un développeur qui installe un framework frontend courant peut, sans le savoir, tirer des dizaines de dépendances de tiers dont aucune ne figure dans sa liste de surveillance. C'est dans ces couches intermédiaires que des attaques comme celle de Miasma prennent racine.
Il y a aussi la question des fuites de données d'identification. Miasma ne vole pas des données applicatives ou des données clients, il vole les clés qui permettent d'accéder à tout le reste. Un token AWS exfiltré peut ouvrir l'accès à des buckets S3 contenant des données sensibles, à des instances EC2, à des secrets Manager. Un token Kubernetes peut permettre l'accès à l'ensemble d'un cluster. Ce que Miasma collecte, ce sont les clés de voûte de votre infrastructure, pas des données périphériques.
Ce chiffre mérite attention : 116 991 téléchargements hebdomadaires. Ce volume signifie que la fenêtre d'exposition, même réduite à quelques heures, a potentiellement touché des milliers d'environnements de développement et de runners CI dans le monde. Si votre organisation fait partie de ces environnements, le fait que npm ait révoqué les paquets rapidement ne supprime pas le risque, il le déplace vers la détection post-exécution.
En premier lieu, toute équipe ayant installé une version affectée de l'un des 32 paquets @redhat-cloud-services entre le 1er juin 2026 à 10h53 UTC et la révocation des versions malveillantes. Semgrep formule la recommandation la plus directe dans son analyse : si vous avez installé une version affectée depuis cette date, considérez l'intégralité de vos secrets CI, clés cloud, clés SSH et tokens npm comme compromis. Pas potentiellement compromis. Compromis.
Les équipes utilisant GitHub Actions dans leurs pipelines sont exposées à une surface d'attaque plus large que ce seul incident. La technique de compromission via OIDC et workflow Actions malveillant n'est pas spécifique à Red Hat, elle peut être appliquée à n'importe quel projet dont les workflows disposent des permissions appropriées et dont un compte contributeur est compromis.
Les organisations qui consomment des paquets npm de grandes marques sans vérification de l'intégrité à l'exécution sont structurellement exposées. La réputation d'un namespace, @redhat-cloud-services, @angular, @aws-sdk, ne constitue pas une garantie de sécurité. Elle crée une fausse confiance que les attaquants exploitent délibérément. OX Security le formule clairement dans son analyse : même les paquets d'organisations reconnues peuvent être compromis si un compte individuel est ciblé avec succès.
Enfin, les équipes de sécurité qui s'appuient exclusivement sur les alertes de vulnérabilité des gestionnaires de paquets, Dependabot, Renovate, audit npm, doivent comprendre que ces outils ne sont pas conçus pour détecter ce type d'attaque. Ils signalent des vulnérabilités connues dans des versions publiées. Ils ne signalent pas qu'une version fraîchement publiée, sans CVE associé, contient un ver actif.
Si votre environnement a exécuté l'un des paquets affectés entre le 1er juin 2026 à 10h53 UTC et la révocation, la priorité absolue est la rotation de tous les secrets présents dans les environnements potentiellement exposés. Cela couvre les tokens GitHub et les secrets de repository Actions, les clés d'accès AWS et les tokens de session associés, les identifiants de comptes de service GCP et Azure, les tokens HashiCorp Vault, les configurations kubeconfig et tokens Kubernetes, les tokens npm et PyPI, les clés SSH privées utilisées dans les pipelines, et les variables d'environnement stockées dans les fichiers .env sur les machines de build.
La vérification des indicateurs de compromission dans vos journaux d'exécution CI/CD est une étape indispensable. Cherchez des appels réseau sortants inattendus depuis vos runners, des accès à des fichiers de configuration hors du répertoire de travail habituel, des appels aux API de métadonnées des fournisseurs cloud depuis des contextes inhabituels.
Sur le plan structurel, l'audit de vos workflows GitHub Actions pour identifier ceux disposant de la permission id-token: write est une action qui peut être menée immédiatement. Cette permission ne devrait être accordée qu'aux workflows qui en ont un besoin fonctionnel explicite et documenté, pas par défaut à l'ensemble des pipelines. La restriction du déclenchement des workflows sensibles à des branches protégées spécifiques, plutôt qu'à branches: ['*'], réduit la fenêtre d'exploitation en cas de compromission d'un compte contributeur.
La mise en place d'une surveillance des publications npm liées à vos namespaces internes, ainsi qu'une vérification systématique des sommes de contrôle lors de l'installation en production, constituent des contrôles que beaucoup d'équipes repoussent faute de temps. Cet incident devrait servir d'argument pour les inscrire dans votre feuille de route de sécurité à court terme.
L'attaque Miasma illustre une réalité que les équipes de sécurité affrontent de plus en plus souvent : les outils qui surveillent votre code ne surveillent pas ce que votre code installe au moment de l'exécution. Les scanners de dépendances vérifient les CVE connus. Ils ne détectent pas un paquet publié il y a deux heures avec un ver actif et zéro signalement.
Defendis surveille en continu l'exposition de votre organisation dans les sources ouvertes, les registres de paquets, et les flux de threat intelligence. Quand des identifiants liés à votre organisation apparaissent dans des données exfiltrées, quand des paquets associés à vos équipes présentent des comportements anormaux, quand des indicateurs de compromission concernant votre périmètre font surface avant que vos outils internes ne les détectent, vous êtes alerté.
La surveillance des indicateurs de compromission liés à votre chaîne d'approvisionnement logicielle, croisée avec la détection précoce de fuites de données d'identification, constitue le complément indispensable à vos contrôles de sécurité applicative. Ce n'est pas une couche supplémentaire de complexité, c'est la visibilité que vos autres outils ne peuvent pas vous offrir.
Les équipes qui ont réagi le plus vite lors de l'incident du 1er juin 2026 sont celles qui disposaient déjà d'une surveillance active de leur périmètre d'exposition externe. Elles n'ont pas attendu la notification npm pour commencer à investiguer. Elles avaient déjà les alertes.
Red Hat a confirmé que ses systèmes internes n'étaient pas compromis. Mon organisation est-elle quand même exposée ? Oui. La compromission concerne le pipeline de publication npm, pas les systèmes de production Red Hat. Si votre organisation a exécuté les paquets affectés dans ses propres environnements, machines de développement, runners CI, conteneurs de build, c'est votre infrastructure qui est potentiellement exposée, indépendamment de ce qui s'est passé chez Red Hat.
Les attestations SLSA ne sont-elles pas censées garantir l'intégrité des paquets ? Les attestations SLSA garantissent que le paquet publié a bien été produit par le workflow de build déclaré, depuis le dépôt source déclaré. Quand c'est le workflow lui-même qui est malveillant, les attestations certifient authentiquement que le malware a été produit par le processus attendu. La provenance est authentique. Le contenu est malveillant. C'est précisément ce que Miasma exploite.
Comment savoir si une version que j'ai installée était malveillante ? Croisez vos fichiers de verrouillage, package-lock.json ou yarn.lock, avec la liste des 96 versions compromises documentées dans les analyses publiées. Vérifiez les horodatages d'installation dans vos journaux de pipeline. Si vous avez installé l'un des 32 paquets du scope @redhat-cloud-services après 10h53 UTC le 1er juin 2026 et avant la révocation, traitez l'environnement comme compromis.
Miasma peut-il se propager entre machines dans un réseau ? Le ver est conçu pour s'exécuter dans le contexte où le paquet est installé et pour exfiltrer les identifiants disponibles dans cet environnement. L'auto-propagation documentée passe par les pipelines CI/CD, en utilisant les tokens GitHub collectés pour infecter d'autres dépôts, plutôt que par une propagation réseau latérale traditionnelle. Cela dit, les tokens collectés peuvent être utilisés par un acteur externe pour effectuer des mouvements latéraux au sein de votre infrastructure cloud.
L'attribution à TeamPCP est-elle certaine ? Non. Aikido Dev et les autres analystes sont explicites sur ce point : la publication en open source du code Shai-Hulud par TeamPCP permet à n'importe quel acteur de reproduire ces techniques. Les similitudes observées dans Miasma sont compatibles avec une convergence de méthodes, pas nécessairement avec une attribution directe.
