Attaque Miasma : le jour où un ver open source a mis à genoux Microsoft et Red Hat

Le 1er juin 2026, une nouvelle attaque de la chaîne d'approvisionnement logicielle s'est discrètement activée, exploitant le compte GitHub compromis d'un employé de Red Hat pour injecter du code malveillant. En quelques jours, ce ver auto-propageant, baptisé Miasma, avait sauté de l'espace de noms npm @redhat-cloud-services pour atterrir au cœur des dépôts publics de Microsoft. Ce qui rend cette attaque unique n'est pas le travail d'un groupe de pirates agissant dans l'ombre : elle a été construite avec une boîte à outils que n'importe qui pouvait télécharger.

Cette boîte à outils, le framework Mini Shai-Hulud, a été publiée en open source le 12 mai 2026 par le groupe de cybercriminels TeamPCP . La suite des événements révèle une nouvelle phase, dangereuse, de la cybersécurité : l'industrialisation des outils d'attaque open source.

Comment l'attaque s'est déroulée : d'un seul compte employé à 73 dépôts Microsoft

La brèche n'a pas commencé par une faille sophistiquée, mais par un simple jeu de mots de passe volés. Les identifiants du compte GitHub d'un salarié de Red Hat étaient disponibles dans des logs d'infostealers depuis le 13 avril 2026 – un laps de temps de près de sept semaines avant leur utilisation malveillante . Avec cet accès, l'attaquant a poussé des commits non autorisés directement dans des dépôts de l'organisation GitHub RedHatInsights .

Ces commits n'avaient rien d'anodin. Dans le dépôt RedHatInsights/javascript-clients, l'attaquant a injecté un workflow GitHub Actions malveillant, demandant des jetons d'identité OIDC et exécutant un code obscurci . Ce code a publié 32 versions de paquets piégés sous l'espace de noms officiel @redhat-cloud-services, chacun portant la signature de campagne “Miasma: The Spreading Blight” . Pire, parce que ces paquets transitaient par le pipeline CI/CD légitime de Red Hat, ils possédaient des signatures de provenance SLSA authentiques, les faisant passer pour vérifiés aux yeux des outils de sécurité .

Ces paquets malveillants totalisaient environ 80 000 téléchargements hebdomadaires . Dès qu'un développeur lançait

npm install

Le comportement le plus novateur du ver n'était pas le vol d'identifiants, mais l'exploitation des outils d'IA de codage. Des variantes de Miasma déposaient des fichiers de règles piégés ciblant Claude Code, Cursor, Gemini CLI et GitHub Copilot, conçus pour s'exécuter automatiquement lorsqu'un développeur clonait et ouvrait le dépôt dans son IDE . En clair, le simple fait de lire le code, sans même installer un paquet, pouvait déclencher l'infection.

Le 5 juin 2026, le ver a atteint Microsoft. Un commit malveillant intitulé « Switched DataConverter to OrchestrationContext [skip ci] » a atterri dans le dépôt Azure/durabletask, avec des métadonnées trafiquées pour afficher une date du 9 mars 2020, afin d'éveiller les soupçons . Ce commit fut la tête de pont. De là, le ver s'est propagé à 73 dépôts dans quatre organisations GitHub de Microsoft : Azure, Azure-Samples, Microsoft et MicrosoftDocs . Parmi les projets touchés figuraient des infrastructures critiques comme azure-functions-host et toute la famille Durable Task (.NET, Go, Java, JavaScript, MSSQL, Python) .

L'origine : TeamPCP et la mise en open source de Mini Shai-Hulud

Pour comprendre Miasma, il faut comprendre la décision de TeamPCP de rendre leur arme publique.

TeamPCP (également suivi sous les noms Replicating Marauder, TGR-CRI-1135, UNC6780) est un groupe qui a passé 2025 et le début 2026 à perfectionner une famille de vers auto-propageants. Leur activité a culminé le 11 mai 2026 avec la publication de 373 versions de paquets malveillants sur 172 paquets npm et PyPI, totalisant plus de 518 millions de téléchargements . Rien que cette campagne a démontré la capacité du ver à extraire des jetons OIDC de la mémoire des runners GitHub Actions pour produire des paquets avec des attestations de provenance valides .

Puis, le 12 mai 2026, TeamPCP a publié l'intégralité du code source de Mini Shai-Hulud sur GitHub sous licence MIT . Parallèlement, le groupe a lancé un concours sur BreachForums, offrant 1 000 dollars en Monero pour la plus grande attaque de la chaîne d'approvisionnement réalisée avec leur framework . Le message était limpide : la boîte à outils appartenait désormais au domaine public.

Dix-sept jours après cette mise en open source, Miasma frappait Red Hat. Le code malveillant est une variante structurelle de Mini Shai-Hulud, avec les références à l'univers de Dune remplacées par une thématique mythologique grecque . Mais la méthode – script preinstall, vol d'identifiants, auto-propagation via CI/CD – est identique .

Un point crucial : les chercheurs ne peuvent pas attribuer Miasma à TeamPCP avec certitude. La Cloud Security Alliance précise que « des acteurs copiant le code source public ne peuvent être exclus » . Unit 42 de Palo Alto Networks renchérit en indiquant que « l'attribution reste incertaine » car le code public permet à tout acteur compétent de répliquer l'attaque . Cette ambiguïté n'est pas anecdotique, c'est une caractéristique délibérée de la stratégie d'open source, conçue pour noyer l'écosystème sous le bruit et submerger les efforts d'attribution .

La vague de copieurs, et l'expansion de l'écosystème

Le framework open source n'a pas seulement rendu Miasma possible : il a engendré une vague immédiate d'activités de copieurs.

Le 3 juin 2026, une variante nommée Phantom Gyp est apparue, touchant 57 paquets npm supplémentaires comme @vapi-ai/server-sdk et ai-sdk-ollama . Cette variante utilisait un fichier binding.gyp piégé pour exécuter du code malveillant, contournant ainsi le hook postinstall désormais sous surveillance . Les chercheurs d'OpenSourceMalware ont confirmé qu'il s'agissait de la première utilisation confirmée du framework TeamPCP, bien que le groupe n'ait jamais revendiqué cette attaque .

Le 8 juin, le SANS Internet Storm Center rapportait que la population des attaquants utilisait activement le framework Mini Shai-Hulud, avec de multiples acteurs indépendants lançant leurs propres campagnes . Le malware s'était même étendu au-delà de npm : une variante Ruby, probablement traduite par un grand modèle de langage (LLM), a été identifiée . Cette vitesse d'adaptation, de npm vers de multiples écosystèmes, souligne à quel point la surface d'attaque a changé.

La réponse des organisations : vitesse, perturbation et politique

La réponse à Miasma a été inhabituellement rapide et publique, reflétant l'ampleur de la compromission.

GitHub a réagi immédiatement. La plateforme a désactivé plus de 70 dépôts de Microsoft en environ 105 minutes après la détection, le 5 juin 2026 . En quelques jours, tous les dépôts ont été restaurés et déclarés sains .

Microsoft a publié une analyse technique détaillée via son équipe Threat Intelligence le 2 juin 2026, couvrant toute la chaîne d'attaque . L'entreprise a aussi pris la décision radicale de retirer 73 de ses propres dépôts, expliquant à BleepingComputer craindre qu'ils ne distribuent du « contenu potentiellement malveillant » . La perturbation de ses propres pipelines CI/CD a démontré que même le propriétaire de la plateforme n'était pas à l'abri.

Red Hat a publié l'avis de sécurité RHSB-2026-006 le 1er juin 2026, confirmant la compromission et précisant que la brèche était limitée aux outils de développement internes, sans impact sur Red Hat Enterprise Linux ou OpenShift . L'entreprise a révoqué toutes les versions de paquets npm affectées.

Le NCSC britannique (National Cyber Security Centre) a transformé l'incident en une initiative politique plus large. Le 4 juin 2026, le NCSC a publié un article de blog exhortant les organisations à auditer leurs dépendances open source . Le 9 juin 2026, le NCSC a publié un « Guide de la chaîne d'approvisionnement Cyber Essentials » actualisé, appelant les entreprises britanniques à faire de la certification Cyber Essentials une exigence standard pour leurs fournisseurs . Les directives portent sur la visibilité (auditer les paquets, maintenir une nomenclature logicielle), l'évaluation (examiner les pratiques de sécurité des fournisseurs) et l'action (sécuriser la chaîne d'approvisionnement au niveau du conseil d'administration) .

Pourquoi Miasma est un tournant : les implications plus larges

L'attaque Miasma n'est pas la plus grande brèche de l'histoire, ni la plus sophistiquée. Mais c'est sans doute la plus instructive pour comprendre ce qui nous attend.

Premièrement, les frameworks d'attaque open source ont armé l'écosystème. La publication de Mini Shai-Hulud était une stratégie délibérée pour créer une armée de copieurs, semer le chaos attributionnel et forcer les défenseurs à lutter contre un nombre inconnu d'acteurs . L'activité des copieurs a été documentée en seulement cinq jours .

Deuxièmement, le hook preinstall de npm est une vulnérabilité systémique. L'attaque exploite une fonctionnalité légitime mais sans contrôle suffisant . L'émergence de binding.gyp comme vecteur d'exécution alternatif dans Phantom Gyp montre que les attaquants cherchent activement de nouveaux hooks à détourner .

Troisièmement, les assistants de codage IA sont devenus une surface d'exécution. Miasma est l'une des premières attaques à cibler Claude Code, Cursor, Copilot et Gemini CLI via des fichiers de règles piégés . Quand un développeur clone un dépôt, l'outil conçu pour écrire un meilleur code exécute un code malveillant. Ce vecteur ne fera que croître avec l'adoption du développement assisté par IA.

Quatrièmement, les pipelines CI/CD sont désormais les cibles les plus critiques. La capacité du ver à produire des paquets avec des attestations SLSA valides signifie que la vérification cryptographique standard peut être déjouée . Sécuriser les pipelines CI/CD contre l'exposition des secrets n'est plus une option.

Enfin, l'intervention gouvernementale a atteint la gestion des dépendances open source. Le guide actualisé du NCSC n'est pas un simple conseil – c'est une demande concrète pour intégrer la sécurité de la chaîne d'approvisionnement dans les achats . Les entreprises qui voient l'audit des dépendances comme une tâche ponctuelle, et non un processus continu, opèrent avec une posture de sécurité dépassée.