Tech-Connect Tech-Connect est un site web proposant des actualités, des tutoriels, des astuces et un forum dans le domaine technologique, informatique, science, télécommunications, mobile, tablette, windows, mac os, linux, opensource, android et IOS. 
Lundi 1er juin 2026. Il est 10h54 UTC. Dans l’obscurité des dépôts GitHub, quelqu’un vient de pousser silencieusement une modification dans un package npm officiel de Red Hat. Pas n’importe quel package, un composant utilisé dans la console hybride cloud de l’une des plus grandes entreprises de logiciels open source au monde. Une modification invisible à l’œil nu, dissimulée dans un script de pré-installation. Une charge qui s’exécute automatiquement dès qu’un développeur tape npm install.
Une heure plus tard, à 13h45, une deuxième vague. Puis une troisième à 14h23. Au total, 95 versions compromises. 32 packages officiels infectés. Et 116 991 téléchargements hebdomadaires potentiellement exposés. L’attaque porte un nom aussi poétique que menaçant : Miasma. Sous-titré « The Spreading Blight », la Corruption qui se propage.
Ce n’est pas une attaque parmi d’autres. C’est la suite directe et encore plus sophistiquée de Mini Shai-Hulud, le ver open source que le groupe TeamPCP avait publié sur GitHub il y a à peine trois semaines. Et ça soulève une question qui devrait tenir éveillé n’importe quel développeur : maintenant que les outils pour construire ce type d’attaque sont accessibles à tout le monde, où s’arrête la contamination ?
Rappel express : c’est quoi une attaque supply chain npm ?
Avant de plonger dans les détails de Miasma, posons les bases pour que tout le monde soit à bord y compris ceux qui ne sont pas développeurs.
npm (Node Package Manager) est le plus grand registre de packages JavaScript au monde. Quand un développeur crée une application web, il n’écrit pas tout le code depuis zéro. Il utilise des briques logicielles préexistantes, appelées packages ou bibliothèques, qu’il installe depuis npm avec une simple commande : npm install nom-du-package. C’est rapide, pratique, et c’est devenu le standard du développement web moderne.
Le problème, c’est que cette confiance implicite dans les packages publiés est précisément ce que les attaquants exploitent. Une attaque supply chain sur npm, c’est glisser du code malveillant à l’intérieur d’un package légitime, de sorte que quand un développeur l’installe, il installe aussi, sans le savoir, le malware avec.
Miasma va plus loin encore. L’attaque ne cible pas un package obscur ou un projet abandonné. Elle prend pour cible le compte officiel @redhat-cloud-services, les packages publiés et maintenus par Red Hat eux-mêmes, l’une des entreprises les plus respectées et les plus utilisées dans l’écosystème Linux et cloud d’entreprise.
📌 C’est quoi Red Hat ? Red Hat est une entreprise américaine fondée en 1993, rachetée par IBM en 2019 pour 34 milliards de dollars. Elle développe et maintient Red Hat Enterprise Linux (RHEL), l’une des distributions Linux les plus utilisées dans les serveurs d’entreprise et les environnements cloud. Ses packages npm servent des millions de développeurs qui construisent sur l’infrastructure cloud Red Hat.
Chronologie de l’attaque : une journée noire pour l’écosystème open source
Voici la reconstitution précise des événements du 1er juin 2026, établie à partir des analyses croisées de Wiz Research, Snyk, Orca Security et Phoenix Security.
| Heure (UTC) | Événement |
| 13 Avril & 15 Mai, 2026 | Whiteintel détecte un identifiant et un cookie de session Red Hat dans des logs d’infostealers sur le dark web, signe que le compte d’un employé Red Hat est déjà compromis |
| 29 mai 2026 | Premiers commits contenant la chaîne « Miasma: The Spreading Blight » détectés par OX Security : phase de test ou préparation |
| 1er juin 2026, 10:54 UTC | 1ère vague : publication de packages malveillants sous @redhat-cloud-services via OIDC tokens volés dans le pipeline CI/CD de Red Hat |
| 1er juin, ~11:30-12:00 UTC | Socket et Aikido signalent les premières versions malveillantes environ 1h après leur publication |
| 1er juin, ~13:00 UTC | Divulgation publique ; la majorité des versions malveillantes sont révoquées par npm ; 2 versions restent actives |
| 1er juin, 13:45 UTC | 2e vague : nouveaux commits malveillants, l’attaquant réagit à la révocation et continue |
| 1er juin, ~14:00 UTC | Wiz publie l’analyse de la cause racine : compte employé compromis + exploitation OIDC |
| 1er juin, 14:23 UTC | 3e vague : confirmée, portant le total à ~95 versions compromises sur 32 packages |
| 2 juin 2026 | Red Hat publie l’avis de sécurité officiel RHSB-2026-006 |
| 2 juin 2026 | Nouvelles versions compromises découvertes dans des packages existants, ajoutées aux listes |
🚨 Ce qui est frappant dans cette chronologie : l’attaquant a continué à publier des vagues après la détection initiale. Quand npm a révoqué les premières versions, il a simplement recommencé. Ce comportement en plusieurs vagues est caractéristique d’un acteur organisé et persistant.
Le point d’entrée : comment l’attaquant s’est glissé dans Red Hat
Voici la question que tout le monde se posait le 1er juin : comment des packages officiels de Red Hat ont-ils pu être compromis ? Red Hat a une équipe de sécurité sérieuse. Ses processus de publication sont normalement rigoureux. Qu’est-ce qui a failli ?
La réponse est à la fois simple et préoccupante : un compte GitHub d’un employé Red Hat a été compromis. Et à partir de là, tout le reste a découlé mécaniquement.
Étape 1 : Compromission du compte en amont
Des données de surveillance du dark web publiées par Whiteintel révèlent qu’un identifiant et un cookie de session appartenant à un employé Red Hat avaient été détectés dans des logs d’infostealers les 13 avril et 15 mai 2026. Cela signifie que le compte de cet employé avait probablement été infecté par un logiciel espion classique par exemple via un email de phishing ou un faux package installé sur sa machine personnelle.
Étape 2 : Contournement de la revue de code
Avec accès au compte GitHub de l’employé, l’attaquant a poussé directement des commits dits « orphelins » dans plusieurs dépôts Red Hat. Un commit orphelin, c’est un commit qui n’est rattaché à aucune branche principale, une technique qui permet de modifier un dépôt en contournant les processus habituels de revue de code par les pairs. Personne ne voit passer une pull request. Personne ne valide. Le code malveillant est là, silencieusement.
Étape 3 : Exploitation des tokens OIDC pour publier sur npm
C’est la partie la plus technique et la plus inquiétante. Les packages Red Hat utilisent GitHub Actions pour leur pipeline de publication automatisée quand un nouveau code est fusionné, GitHub Actions se charge de publier automatiquement la nouvelle version sur npm. Pour cela, il utilise des tokens OIDC (Open ID Connect), des jetons d’authentification éphémères générés par GitHub et valides uniquement pour la durée d’un workflow.
L’attaquant a inséré dans les workflows GitHub Actions un script qui intercepte ces tokens en lisant directement la mémoire du processus runner, la même technique documentée dans Mini Shai-Hulud. Avec ces tokens, il a pu publier ses propres versions malveillantes sur npm, signées avec des identifiants légitimes de Red Hat. Résultat : les packages malveillants portaient une signature cryptographique valide. Les outils de vérification d’intégrité standard ont vu des packages authentiques.
Ce que l’attaquant a injecté dans le workflow GitHub Actions :
- Lecture de la mémoire du runner pour extraire les tokens OIDC
- puis publication via : npm publish –access public
- avec des attestations SLSA Build Level 3 forgées mais valides
💡 Pour les non-développeurs : imaginez que l’attaquant a réussi à voler le tampon officiel de Red Hat et à s’en servir pour apposer une signature « certifiée authentique » sur ses propres packages piégés. Tous les contrôles automatiques ont vu un cachet valide et ont laissé passer.
Le mécanisme du ver Miasma : Comment il s’exécute
Une fois le package malveillant publié, son fonctionnement est redoutablement simple à déclencher et très difficile à arrêter.
L’exécution automatique au moment de l’installation
Le code malveillant est inséré dans un script dit « preinstall », un script qui s’exécute automatiquement avant même que le package soit chargé dans votre projet. Cela signifie que vous n’avez pas besoin d’importer le package dans votre code, de l’utiliser, ou même de démarrer votre application. La seule commande npm install suffit à déclencher le malware. Immédiatement, silencieusement.
Architecture technique du payload
La charge utile de Miasma est construite sur le même framework que Mini Shai-Hulud, dont voici les caractéristiques techniques principales :
- Obfuscation en 4 couches pour résister aux analyses statiques des scanners de sécurité.
- Utilisation de Bun (un runtime JavaScript alternatif) pour exécuter le payload de manière plus discrète.
- Staging du payload malveillant via le répertoire /tmp : espace temporaire rarement surveillé.
- Extraction d’identifiants en mémoire via /proc/mem : contourne les protections de logs standard.
- Propagation automatique : le ver énumère les dépôts GitHub auxquels le token volé a accès, lit les fichiers de workflow via l’API GraphQL, et publie de nouvelles versions infectées via la mutation createCommitOnBranch faisant apparaître ses commits comme des changements vérifiés et signés.
- Persistance dans les configs IA : modification de .claude/settings.json pour survivre au nettoyage du package.
- Chiffrement AES-128-GCM pour les communications exfiltrées.
La nouveauté de la deuxième vague
La deuxième vague de publications, détectée à 13h45 UTC, a introduit de nouveaux collecteurs spécifiques pour les identités Google Cloud Platform (GCP) et Microsoft Azure en plus des cibles AWS déjà présentes dans la première vague. Cela démontre une adaptation en temps réel : l’attaquant a observé les premières analyses publiées sur les réseaux sociaux et a enrichi son arsenal pendant que l’attaque était encore en cours.
Ce que Miasma vole exactement
La charge utile de Miasma est un aspirateur à secrets particulièrement vorace. Voici ce qu’elle cible, d’après les analyses techniques publiées par Snyk, Wiz, Orca Security et Phoenix Security :
| Catégorie | Données ciblées | Impact potentiel |
| Cloud AWS | Clés IAM (~/.aws/credentials), tokens de session temporaires | Accès total à l’infrastructure AWS de la victime |
| Cloud GCP | Clés de compte de service (.json), tokens gcloud | Déploiements, accès aux données, coûts de calcul frauduleux |
| Cloud Azure | Identités de service, tokens Azure CLI | Accès aux ressources Microsoft Azure |
| GitHub | Tokens d’accès personnels (PAT), secrets GitHub Actions | Accès aux dépôts privés, publication malveillante |
| npm | Tokens de publication npm (~/.npmrc) | Publication de packages malveillants sous votre identité |
| SSH | Clés privées SSH (~/.ssh/) | Accès aux serveurs, VPS, infrastructure DevOps |
| Kubernetes | Fichiers kubeconfig (~/.kube/config) | Contrôle de clusters Kubernetes en production |
| Outils IA | Fichiers config Claude Code, VS Code tasks | Persistance post-nettoyage, compromission des sessions futures |
| Gestionnaires de secrets | Variables d’environnement, HashiCorp Vault tokens | Accès à tous les secrets d’application |
🔴 Le danger multiplicateur : une fois en possession de votre token npm, le ver ne s’arrête pas à vous. Il scanne automatiquement tous les dépôts GitHub auxquels votre compte a accès et tente de publier des versions infectées dans d’autres packages dont vous êtes maintenant le vecteur involontaire.
Le lien avec Mini Shai-Hulud : quand l’open source devient une arme
Pour comprendre Miasma, il faut revenir en arrière de trois semaines. Le 12 mai 2026, le groupe de hackers TeamPCP publie sur GitHub le code source complet de son ver Mini Shai-Hulud, l’accompagnant de posts sur BreachForums encourageant explicitement des campagnes indépendantes.
En publiant leur code, TeamPCP transforme une attaque sophistiquée réservée à des acteurs bien dotés en un kit accessible à n’importe quel développeur malveillant avec un niveau technique modéré. Trois semaines plus tard, Miasma fait son apparition.
Les liens techniques entre les deux sont indéniables selon les chercheurs en sécurité :
- Même structure de payload en quatre couches d’obfuscation.
- Même usage de Bun comme runtime d’exécution.
- Même technique d’extraction de mémoire via /proc/mem.
- Même persistance via .claude/settings.json.
- Même mécanisme de propagation auto-réplicante via les tokens npm volés.
Ce qui diffère, c’est le registre culturel. Là où Mini Shai-Hulud puisait dans l’univers de Dune pour ses références (les vers des sables de Frank Herbert), Miasma bascule vers la mythologie grecque « miasma » désignant dans la Grèce antique une pollution spirituelle contagieuse, une souillure qui se propage. Un choix de nom qui, au fond, décrit parfaitement ce que fait le malware.
🔍 Attribution : les chercheurs de Phoenix Security précisent qu’il est impossible de confirmer avec certitude que Miasma est directement l’œuvre de TeamPCP plutôt que d’un acteur indépendant ayant adapté leur code public. Le délai de trois semaines entre la publication du code source et l’attaque suggère qu’un groupe différent, peut-être moins expérimenté mais opportuniste, a étudié le framework et l’a amélioré pour cibler Red Hat.
Les autres victimes : Miasma n’est pas seul
Miasma n’est pas un incident isolé. Il s’inscrit dans une série d’attaques supply chain qui touchent l’écosystème open source depuis le début de l’année 2026. Voici le panorama des principales victimes documentées depuis mars 2026 :
| Projet victime | Date | Mécanisme d’attaque | Impact |
| LiteLLM (PyPI) | Mars 2026 | Identifiants du maintaineur compromis | Aspirateur de clés API IA (OpenAI, Anthropic…) |
| Mistral AI SDK (npm + PyPI) | Avr.–Mai 2026 | OIDC pipeline compromis | Tokens d’accès Mistral exfiltrés |
| TanStack (npm) | Mai 2026 | Cache poisoning GitHub Actions | 2 appareils d’employés OpenAI compromis |
| SAP CAP + mbt (npm) | Mai 2026 | Backdoor Bun + credential stealer | Persistance .claude/settings.json |
| Microsoft DurableTask (PyPI) | 19 mai 2026 | Compte GitHub maintainer hijacké | Secrets CI/CD entreprise |
| @redhat-cloud-services (npm) | 1er juin 2026 | Compte employé + OIDC exploit | 117 000 dl/sem, 95 versions infectées |
Ce panorama révèle une tendance inquiétante : les attaquants diversifient leurs vecteurs d’entrée (maintaineur compromis, OIDC exploit, cache poisoning, hijacking de compte employé) et s’adaptent rapidement aux contre-mesures déployées par les registres. La publication du code source de Mini Shai-Hulud a transformé ce qui était une technique de niche en une tactique quasi-industrielle.
Suis-je concerné ? Le guide de vérification
C’est la question la plus importante. Voici comment déterminer si vous êtes potentiellement exposé, et quoi faire si c’est le cas.
🔍 Vérification rapide : Êtes-vous dans la fenêtre d’exposition ?
Vous êtes potentiellement affecté si vous avez exécuté npm install sur un projet qui dépend d’un package @redhat-cloud-services entre le 1er juin 2026, 10:54 UTC et la révocation complète des versions malveillantes.
Pour vérifier si votre projet dépend de packages @redhat-cloud-services :
# Dans le répertoire de votre projet :
npm list | grep @redhat-cloud-services
# ou dans votre package.json / package-lock.json :
grep -r ‘redhat-cloud-services’ package*.json
Les packages les plus touchés incluent notamment @redhat-cloud-services/topological-inventory-client, @redhat-cloud-services/compliance-client, et @redhat-cloud-services/rbac-client. La liste complète est disponible sur le blog Wiz.
🚨 Actions immédiates si vous êtes exposé
- Révoquez et régénérez IMMÉDIATEMENT toutes vos clés AWS, GCP et Azure présentes sur les machines concernées.
- Changez tous vos tokens GitHub (Personal Access Tokens et tokens d’organisation).
- Régénérez vos tokens de publication npm (~/.npmrc).
- Vérifiez vos clés SSH : si elles étaient présentes dans ~/.ssh/ sur la machine infectée, considérez-les comme compromises.
- Inspectez .claude/settings.json dans vos dépôts et votre répertoire home, cherchez des entrées SessionStart suspectes.
- Auditez vos logs de pipeline CI/CD pour des publications non autorisées de packages.
- Vérifiez vos factures cloud pour des utilisations anormales des derniers jours.
🔴 Ne faites pas ces rotations par email ou Slack, si votre système est compromis, ces communications pourraient être interceptées. Utilisez un appareil de confiance non affecté pour révoquer et régénérer vos identifiants.
✅ Actions préventives pour l’avenir
- Mettez à jour vers les versions saines des packages @redhat-cloud-services en vous référant à l’avis officiel RHSB-2026-006 de Red Hat.
- Vérifiez et nettoyez vos fichiers .vscode/tasks.json pour des tâches runOn: folderOpen non attendues.
- Activez les alertes de sécurité npm audit dans votre pipeline CI/CD.
- Activez npm audit –audit-level=moderate dans vos scripts de build.
Comment mieux se protéger ?
Miasma soulève des questions fondamentales sur la confiance dans l’écosystème open source. Voici les mesures les plus efficaces pour limiter votre exposition à ce type d’attaques, classées par niveau de complexité.
🟢 Niveau débutant (à faire immédiatement, partout)
- Verrouillez vos dépendances avec des hashes de contenu dans package-lock.json, cela empêche les mises à jour automatiques vers une version non vérifiée.
- Activez npm audit dans votre pipeline CI/CD : npm le fait automatiquement lors des installations si configuré.
- Ne stockez jamais d’identifiants cloud ou de tokens API directement dans votre environnement de développement sans gestionnaire de secrets.
🟡 Niveau intermédiaire (pour les équipes)
- Auditez régulièrement vos GitHub Actions workflows pour la mauvaise configuration pull_request_target qui permet le cache poisoning.
- Isolez les permissions CI/CD : chaque workflow ne doit avoir accès qu’aux secrets dont il a strictement besoin.
- Utilisez des outils de composition logicielle (SCA) comme Snyk, Socket ou Dependabot pour surveiller vos dépendances en continu.
- Intégrez .claude/settings.json et .vscode/tasks.json dans votre politique de surveillance d’intégrité des fichiers.
🔴 Niveau avancé (entreprises et projets critiques)
- Déployez un miroir privé de vos dépendances npm avec Verdaccio ou JFrog Artifactory : vous contrôlez exactement quelles versions entrent dans vos pipelines.
- Mettez en place une analyse comportementale des scripts preinstall avant exécution : des outils comme Socket.dev analysent le code des packages avant l’installation.
- Considérez la politique de « délai de vérification » : n’utilisez jamais une version d’un package publiée il y a moins de 48 heures dans vos pipelines de production.
💡 Outil gratuit utile : Socket.dev propose une extension VS Code et une intégration GitHub qui analyse les packages npm en temps réel et vous alerte dès qu’un package présente des comportements suspects comme l’accès réseau lors de l’installation.
Le bilan de l’incident
| Indicateur | Chiffre / Statut |
| Packages compromis | 32 packages dans @redhat-cloud-services |
| Versions malveillantes publiées | ~95 versions (3 vagues) |
| Téléchargements hebdo. combinés | 116 991 downloads/semaine |
| Fenêtre d’exposition | 1er juin 2026, 10:54 UTC → révocations progressives |
| Temps avant première détection | ~1 heure (Socket et Aikido) |
| Temps avant révocation | ~2 heures |
| Outils de détection ayant alerté | Socket, Aikido, JFrog, Snyk, Wiz, Orca, Microsoft |
| Avis officiel Red Hat | RHSB-2026-006 (publié le 2 juin 2026) |
| Lien avec Mini Shai-Hulud | Dérivé direct du code open sourcé le 12 mai 2026 |
| Attribution confirmée | Non, acteur utilisant l’outillage TeamPCP, identité inconnue |
Le modèle de confiance de npm est fondé sur la réputation des mainteneurs. Miasma a compromis un compte employé Red Hat et a publié des packages avec des signatures cryptographiques valides. Est-ce que ce modèle de confiance est encore viable ? Faut-il repenser la façon dont on publie et consomme des packages open source ?
