Le 1er juin 2026, les chercheurs de Wiz Research ont publie une alerte critique concernant une compromission supply chain ciblant les paquets npm du scope @redhat-cloud-services. L analyse, confirmee independamment par Aikido Security, revele que 32 paquets ont ete compromis avec un total de 96 versions malveillantes publiees sur le registre npm. Ces paquets, utilises principalement par les equipes qui developpent et deploient des applications sur la plateforme cloud de Red Hat, totalisent environ 80 000 telechargements hebdomadaires. Le malware injecte, baptise Miasma: The Spreading Blight, represente une evolution significative de la famille de malware Mini Shai-Hulud que nous avions deja analysee dans notre article sur la compromission TanStack et 169 paquets npm.
Ce qui rend cette attaque particulierement alarmante, c est qu elle touche Red Hat — un pilier de l ecosysteme open source, une entreprise dont la reputation est batie sur la fiabilite et la securite de ses solutions d entreprise. Si Red Hat peut etre compromis de cette maniere, le message est clair : aucune organisation, quelle que soit sa taille ou sa maturite en securite, n est a l abri des attaques supply chain sur npm. Le vecteur d attaque est le meme que celui qui a frappe TanStack, Axios et des centaines d autres paquets en 2026 : la compromission du pipeline CI/CD via des tokens OIDC GitHub Actions. L attaque a ete attribuee au groupe TeamPCP, le meme acteur de menace responsable de la vague d attaques supply chain qui secoue l ecosysteme npm depuis le debut de l annee, et dont nous avions detaille les methodes lors de l attaque des 317 packages npm en mai 2026.
La CISA (Cybersecurity and Infrastructure Security Agency) a reagi rapidement en ajoutant les CVE associes — CVE-2026-45321 avec un score CVSS de 9.6 et CVE-2026-48027 avec un score CVSS de 9.3 — a son catalogue KEV (Known Exploited Vulnerabilities) des le 27 mai 2026, avec une date limite de remediation fixee au 10 juin 2026. Pour toute equipe utilisant des paquets @redhat-cloud-services dans ses projets ou pipelines CI/CD, l action est requise maintenant — pas la semaine prochaine.
💡 Notre avis d'expert
La publication OIDC sur npm est fondamentalement cassee. Le modele OIDC verifie d ou le code est execute, pas quel code est execute. Quand TeamPCP compromet un compte GitHub ayant acces au pipeline CI/CD de Red Hat, il peut publier des paquets malveillants avec l identite OIDC de confiance du projet. Pour npm, c est une release authentique. Pour le developpeur qui installe le paquet, c est un cheval de Troie signe par Red Hat. Tant que npm ne verifiera pas le contenu du code source par rapport a un commit audite et signe, ce vecteur d attaque restera grand ouvert. L OIDC n est pas une protection — c est un vecteur d attaque deguise en couche de securite.
Anatomie de l attaque : du compte compromis au credential stealer Bun
L attaque contre les paquets @redhat-cloud-services suit un schema desormais familier dans l arsenal de TeamPCP, mais avec des innovations techniques significatives par rapport aux attaques precedentes. Voici la chaine d attaque complete, telle que reconstituee par les chercheurs de Wiz et d Aikido.
Phase 1 : Compromission du compte GitHub. Le point d entree est un compte employe Red Hat sur GitHub qui a ete compromis. Contrairement aux attaques precedentes de TeamPCP — ou l exploitation passait par des workflows pull_request_target mal configures — ici, l attaquant a obtenu un acces direct au compte d un developpeur Red Hat ayant des droits sur les repositories des paquets @redhat-cloud-services. Le vecteur exact de compromission du compte n a pas encore ete confirme publiquement — credential stuffing, phishing cible, ou vol de session token sont les hypotheses principales. Ce qui est confirme, c est que l attaquant a utilise ce compte pour declencher les workflows GitHub Actions de publication des paquets.
Phase 2 : Publication via OIDC GitHub Actions. Une fois le compte compromis, l attaquant a utilise les workflows CI/CD existants de Red Hat pour publier les versions malveillantes sur npm. Les paquets n ont pas ete publies manuellement — ils ont ete publies via les tokens OIDC generes par GitHub Actions, ce qui signifie que du point de vue de npm, les publications etaient parfaitement legitimes. Le registre npm a vu des paquets publies depuis le bon repository, par le bon workflow, avec une attestation OIDC valide. C est le meme mecanisme que celui exploite lors de l attaque TanStack, mais applique a un scope organisationnel de Red Hat. Le fait que ce vecteur soit reutilise un mois apres TanStack — sans aucune modification structurelle du cote de npm ou GitHub — est revelateur de l inertie de l ecosysteme face a ces menaces.
Phase 3 : Injection du payload Miasma. Chaque version malveillante embarque un tarball de 4.1 Mo contenant du JavaScript massivement obfusque, declenche en tant que hook preinstall. La taille du fichier est anormalement elevee pour un hook de ce type — c est un indicateur clair de compromission que les outils de scanning auraient du detecter, mais que la plupart des configurations par defaut ignorent. Le script obfusque constitue le premier etage d un loader multi-etapes : il decode et execute du code supplementaire telecharge depuis des serveurs de commande et controle, rendant l analyse statique extremement difficile.
Phase 4 : Credential stealer execute par Bun. L innovation majeure de Miasma par rapport a Mini Shai-Hulud est l utilisation du runtime Bun pour executer le payload final au lieu de Node.js. Bun offre des performances d execution superieures et — surtout — un footprint different dans les outils de monitoring. Les regles de detection EDR (Endpoint Detection and Response) configurees pour surveiller les processus Node.js suspects ne detectent pas les memes patterns quand le code est execute via Bun. Le credential stealer cible un spectre plus large que Mini Shai-Hulud : en plus des tokens GitHub, npm et CI/CD classiques, Miasma embarque des collecteurs dedies pour GCP et Azure cloud identities, ainsi que pour HashiCorp Vault, Kubernetes service accounts, et les credentials stockes dans Bitwarden et 1Password.
Phase 5 : Persistance via service monitoring. La derniere phase de l attaque est ce qui distingue veritablement Miasma des malwares supply chain precedents. Apres avoir exfiltre les credentials, Miasma installe un service de monitoring persistant sur la machine victime. Sur Linux, il cree le fichier kitty-monitor.service dans /etc/systemd/system/, active via systemd pour survivre aux redemarrages. Sur macOS, c est le fichier com.user.kitty-monitor.plist dans ~/Library/LaunchAgents/. Ce service surveille en continu les nouvelles variables d environnement et les fichiers de credentials qui apparaissent sur le systeme, exfiltrant tout nouveau secret des qu il est detecte. C est un changement de paradigme : au lieu d un vol ponctuel, Miasma etablit une surveillance permanente de la machine de developpement.
💡 Notre avis d'expert
La reponse de Red Hat est trop lente. Entre le moment ou les premieres versions malveillantes ont ete publiees et l alerte publique de Wiz, il s est ecoule un delai inacceptable pour une organisation de cette envergure. Red Hat dispose de ressources de securite considerables — Product Security, RHEL Security Response Team, des dizaines d ingenieurs securite dedies. Le fait que la compromission ait ete detectee par un tiers (Wiz) et non par les equipes internes de Red Hat est un signal d alarme. Cela suggere que les mecanismes de monitoring interne des publications npm de Red Hat sont insuffisants ou absents. Pour un editeur dont les paquets sont utilises dans des environnements de production cloud critiques, c est une lacune grave.
Miasma vs Mini Shai-Hulud vs attaques npm precedentes : le tableau comparatif
Pour comprendre l evolution des attaques supply chain npm en 2026, voici une comparaison detaillee entre Miasma, Mini Shai-Hulud et l attaque des 317 packages de mai 2026. Chaque attaque represente une montee en sophistication par rapport a la precedente.
| Critere | Miasma (juin 2026) | Mini Shai-Hulud (mai 2026) | 317 packages (mai 2026) |
|---|---|---|---|
| Cible principale | @redhat-cloud-services (32 paquets) | @tanstack/* (42 paquets) | 317 packages divers |
| Versions malveillantes | 96 | 84 | 630+ |
| Vecteur d attaque | Compte GitHub compromis + OIDC | pull_request_target + cache poison + OIDC | Compte npm mainteneur compromis |
| Runtime du payload | Bun | Node.js | Node.js |
| Persistance | systemd + LaunchAgents | Non (vol ponctuel) | Non (vol ponctuel) |
| Cibles credentials | AWS, Azure, GCP, Vault, K8s, OIDC, Bitwarden, 1Password | GitHub, npm, CI/CD, cloud tokens | Passwords, cloud, CI/CD |
| Taille du payload | 4.1 Mo | ~800 Ko | ~200 Ko |
| CVE CVSS | 9.6 + 9.3 | 9.6 | Non attribue |
| Acteur de menace | TeamPCP | TeamPCP | Non confirme |
La progression est claire. Entre l attaque des 317 packages (compromission directe de compte npm), Mini Shai-Hulud (exploitation de workflows GitHub Actions avec OIDC), et maintenant Miasma (compromission de compte GitHub employe + OIDC + persistance + Bun), TeamPCP affine ses techniques a chaque iteration. Chaque attaque est plus difficile a detecter et plus devastatrice que la precedente. L ajout de la persistance via des services systeme est un saut qualitatif — l attaquant ne se contente plus de voler vos credentials a l instant T, il installe une surveillance permanente qui capture tout nouveau secret que vous configurez apres l attaque initiale.
Timeline des attaques supply chain npm en 2026 : une escalade sans precedent
L attaque Miasma ne peut pas etre analysee isolement. Elle s inscrit dans une vague d attaques supply chain npm sans precedent qui a marque le premier semestre 2026. Voici la timeline complete des incidents majeurs attribues a TeamPCP ou lies a la meme campagne.
La cadence est alarmante : une attaque majeure par mois depuis fevrier 2026, avec une sophistication croissante a chaque iteration. TeamPCP ne se contente pas de repeter les memes techniques — le groupe adapte et ameliore son arsenal en fonction des defenses mises en place apres chaque incident. L ajout du runtime Bun dans Miasma est une reponse directe aux regles de detection EDR deployees apres Mini Shai-Hulud. La persistance via systemd et LaunchAgents est une reponse au fait que les precedentes victimes se contentaient de rotationner leurs tokens sans nettoyer leurs machines. Chaque mesure defensive est analysee et contournee dans la version suivante du malware.
💡 Notre avis d'expert
L ecosysteme npm a besoin d une reforme radicale de son modele de dependances. Le modele actuel ou n importe quel paquet peut executer du code arbitraire a l installation via des hooks preinstall/postinstall est une aberration de securite. Imaginez un monde ou telecharger une bibliotheque C ne declenche pas automatiquement l execution de code arbitraire sur votre machine — c est le cas avec la plupart des gestionnaires de packages systeme (apt, dnf). npm est une exception dangereuse. La solution passe par : 1) la desactivation des hooks d installation par defaut avec opt-in explicite, 2) des builds reproductibles obligatoires pour la publication, 3) une verification du code source par rapport au commit de reference. Tant que ces changements ne seront pas implementes, chaque npm install est un acte de foi.
Votre projet est-il affecte ? L arbre de decision
La compromission de paquets Red Hat touche potentiellement un spectre large de projets : toute equipe qui developpe, deploie ou gere des applications sur la plateforme cloud de Red Hat (OpenShift, RHEL, etc.) utilise probablement des paquets du scope @redhat-cloud-services. L arbre de decision ci-dessous vous aide a evaluer votre exposition.
Ce que ca signifie pour vous — le modele OSS doit changer
La compromission des paquets Red Hat est plus qu un incident de securite isole — c est un symptome d un probleme systemique dans le modele de dependances open source. Quand une organisation comme Red Hat, avec ses milliers d ingenieurs, ses processus de securite matures, et son heritage de decades dans la securisation de logiciels d entreprise, se fait compromettre via le meme vecteur que des projets individuels geres par un seul mainteneur, cela demontre que le probleme n est pas dans les pratiques des organisations — c est dans l architecture meme de l ecosysteme npm.
Le probleme fondamental : confiance implicite. Quand vous faites npm install @redhat-cloud-services/some-package, vous faites confiance a une chaine qui comprend : le compte GitHub de l employe Red Hat, le workflow GitHub Actions, le token OIDC, le registre npm, et le contenu du paquet. Si n importe quel maillon de cette chaine est compromis, tout s effondre. Et la compromission d un seul compte GitHub suffit a compromettre l ensemble de la chaine. C est la definition meme d un single point of failure dans un systeme distribue — exactement ce que l architecture logicielle moderne est censee eviter.
Les actions concretes que vous devez prendre maintenant :
1. Auditez immediatement vos dependances Red Hat. Executez grep -r "@redhat-cloud-services" package.json package-lock.json pnpm-lock.yaml dans tous vos projets. Si vous trouvez des references, verifiez les versions installees contre la liste des versions compromises publiee par Wiz. Forcez une reinstallation propre avec npm ci apres avoir mis a jour votre lockfile.
2. Recherchez les indicateurs de compromission Miasma. Sur Linux : ls -la /etc/systemd/system/kitty-monitor.service. Sur macOS : ls -la ~/Library/LaunchAgents/com.user.kitty-monitor.plist. Si ces fichiers existent, votre machine est compromise. Desactivez immediatement le service, nettoyez les fichiers, et considerez une reinstallation complete du systeme.
3. Rotez TOUS vos credentials. Si vous avez installe une version compromise, partez du principe que tous vos secrets ont ete exfiltres : tokens AWS, Azure, GCP, secrets HashiCorp Vault, tokens Kubernetes, tokens GitHub, tokens npm, mots de passe Bitwarden et 1Password. Rotez tout. Changez vos mots de passe. Revoquez et regenerez tous vos tokens d acces. Notre guide pour securiser votre pipeline npm contre les attaques supply chain detaille la procedure complete.
4. Desactivez les hooks preinstall/postinstall. Configurez npm pour ignorer les scripts d installation par defaut : npm config set ignore-scripts true. Puis autorisez explicitement les scripts pour les paquets qui en ont legitimement besoin. C est plus contraignant mais c est la seule defense fiable contre les payloads injectes dans les hooks d installation. Ajoutez un fichier .npmrc avec ignore-scripts=true a la racine de chaque projet.
5. Implementez la surveillance des publications npm de vos dependances critiques. Utilisez des outils comme Socket.dev pour monitorer en temps reel les nouvelles versions de vos dependances et detecter les comportements suspects (acces reseau, lecture de fichiers systeme, acces aux variables d environnement). Configurez des alertes pour toute publication anormale : taille de tarball inhabituelle, ajout de hooks d installation, changement d auteur.
Besoin d un audit de securite de vos dependances npm et pipelines CI/CD ?
Audit des publications OIDC, detection Miasma, rotation des secrets cloud, configuration Socket.dev, securisation des workflows GitHub Actions — notre equipe vous accompagne de A a Z.
Obtenir mon devis gratuitPrediction : pourquoi Q3 2026 sera pire
Si l on analyse la trajectoire de TeamPCP depuis fevrier 2026, la tendance est claire : les attaques vont continuer a s intensifier au troisieme trimestre. Voici pourquoi.
Le vecteur OIDC n a pas ete corrige. Ni npm ni GitHub n ont implemente de changement structurel depuis l attaque TanStack de mai 2026. Les tokens OIDC GitHub Actions continuent de permettre la publication sur npm sans verification du contenu du code. Chaque organisation qui publie des paquets npm via OIDC est une cible potentielle. Et il y en a des milliers. TeamPCP a demontre avec Miasma qu il peut exploiter ce vecteur contre n importe quelle organisation, meme celles avec les meilleures pratiques de securite.
Le Bun runtime ouvre un nouveau front d evasion. L utilisation de Bun dans Miasma montre que TeamPCP cherche activement a eviter les regles de detection construites apres les attaques precedentes. Le Q3 verra probablement des variantes utilisant d autres runtimes alternatifs — Deno, des WebAssembly workers, ou meme des binaires natifs compiles par le payload JavaScript. Chaque runtime alternatif necessite des regles de detection specifiques, et la plupart des equipes de securite ne sont pas preparees a cette diversification.
La persistance va devenir la norme. Avec Miasma, TeamPCP a demontre que la persistance est non seulement possible mais pratique. Les prochaines variantes iront probablement plus loin : injection dans les fichiers de configuration shell (.bashrc, .zshrc), modification des configurations git pour intercepter les credentials, ou meme compromission des outils de developpement locaux (extensions VS Code, plugins IDE). La machine du developpeur est la cible ultime, et Miasma n est que la premiere generation de malware qui s y installe durablement.
💡 Notre avis d'expert
Le Q3 2026 verra plus d attaques CI/CD pipeline, pas moins. TeamPCP a trouve un modele qui fonctionne : compromettre un compte, utiliser le pipeline legitime pour publier, recolter des credentials. Chaque attaque reussie genere des credentials voles qui servent de point de depart pour la suivante. C est un effet boule de neige. Les credentials Red Hat voles via Miasma seront probablement utilises pour compromettre d autres organisations dans les semaines qui viennent. Nous recommandons a toute equipe utilisant npm en production de traiter la securite supply chain comme une priorite P0 — pas un nice-to-have, pas un ticket dans le backlog, une priorite P0 au meme titre que la securite des donnees utilisateurs.
FAQ
Quels paquets npm Red Hat ont ete compromis par le malware Miasma en juin 2026 ?
32 paquets du scope @redhat-cloud-services sur npm ont ete compromis avec 96 versions malveillantes. Ces paquets totalisent environ 80 000 telechargements hebdomadaires. Le malware Miasma: The Spreading Blight a ete injecte via des hooks preinstall contenant 4.1 Mo de JavaScript obfusque. Les paquets ont ete publies via des tokens OIDC GitHub Actions apres la compromission d un compte employe Red Hat sur GitHub. La CISA a ajoute les CVE associes (CVE-2026-45321 CVSS 9.6 et CVE-2026-48027 CVSS 9.3) a son catalogue KEV avec une date limite de correction au 10 juin 2026.
Qu est-ce que le malware Miasma: The Spreading Blight et quel est son lien avec Mini Shai-Hulud ?
Miasma: The Spreading Blight est une nouvelle variante de la famille de malware Mini Shai-Hulud, identifiee par Wiz Research le 1er juin 2026. Comme Mini Shai-Hulud, Miasma est un credential stealer multi-etapes, mais avec des capacites etendues : nouveaux collecteurs pour GCP et Azure cloud identities, execution via le runtime Bun au lieu de Node.js (pour evader les regles de detection EDR), et installation d un service de monitoring persistant (kitty-monitor.service sur Linux, com.user.kitty-monitor.plist sur macOS) qui surveille en continu les nouvelles credentials apparaissant sur le systeme.
Comment savoir si mon projet est affecte par la compromission des paquets Red Hat npm ?
Verifiez si votre projet utilise des paquets du scope @redhat-cloud-services dans votre package.json ou lockfile avec la commande grep -r "@redhat-cloud-services" package.json package-lock.json pnpm-lock.yaml. Executez npm audit ou pnpm audit. Recherchez les fichiers kitty-monitor.service dans /etc/systemd/system/ sur Linux ou com.user.kitty-monitor.plist dans ~/Library/LaunchAgents/ sur macOS. Si ces fichiers existent, votre machine est compromise — desactivez le service, nettoyez les fichiers, et rotez immediatement tous vos secrets cloud, CI/CD et gestionnaires de mots de passe.
Pourquoi la publication OIDC sur npm est-elle fondamentalement vulnerable aux attaques supply chain ?
La publication OIDC verifie d ou le code est execute (quel repository, quel workflow), mais pas quel code est execute. Si un attaquant compromet un compte GitHub ayant acces au pipeline CI/CD d un projet, il peut declencher une publication via le workflow legitime avec l identite OIDC de confiance du projet. npm recoit un paquet signe par une identite OIDC valide et l accepte sans question. La signature OIDC devient alors une arme au lieu d une protection. C est exactement ce qui s est passe avec Red Hat, TanStack et les autres victimes de TeamPCP en 2026. Tant que npm ne verifie pas le contenu du code source par rapport a un commit specifique et audite, ce vecteur d attaque restera grand ouvert.
Securisez vos dependances npm et vos pipelines de publication
Detection Miasma, audit OIDC, rotation des secrets multi-cloud, configuration Socket.dev, securisation GitHub Actions — notre equipe d experts securite vous accompagne.
Demander un accompagnement