Ver Miasma : comment une supply chain attack a compromis 73 dépôts GitHub Microsoft via les outils IA (Claude Code, Cursor, Gemini CLI)

Le 5 juin 2026, un ver informatique baptisé "Miasma" s'est propagé à travers 73 dépôts GitHub appartenant à Microsoft. La particularité de cette attaque ? Elle exploite non pas une faille dans le code de Microsoft, mais la confiance aveugle que les développeurs accordent à leurs outils de développement assistés par IA. Claude Code, Cursor, Gemini CLI, VS Code : autant de portes d'entrée qu'un payload soigneusement camouflé a su utiliser pour se répandre de façon autonome.

Ce qui s'est passé le 5 juin 2026 : retour sur les faits

Tout commence par un dépôt en apparence anodin : Azure/durabletask, un projet open source que Microsoft maintient activement et que des milliers de développeurs utilisent pour orchestrer des workflows durables dans Azure. Le 5 juin, un commit malveillant y est injecté. Pas par un hacker qui aurait cracké les serveurs de Microsoft, mais via les credentials d'un contributeur légitime, volés en amont.

Ce premier commit est la graine. À l'intérieur se trouve un payload — c'est-à-dire la charge utile malveillante, le "vrai" code offensif — conçu pour se déclencher dans un contexte très précis : celui d'un environnement de développement IA-assisté. Dès qu'un développeur ouvre ce dépôt infecté dans Claude Code, Cursor, Gemini CLI ou VS Code avec certaines extensions activées, le payload s'exécute.

La première action du ver : voler les credentials du développeur. Jetons d'authentification GitHub, clés d'accès Azure, tokens d'API — tout ce qui traîne dans l'environnement local est aspiré. Ensuite, armé de ces nouveaux accès, Miasma se propage de façon entièrement autonome vers d'autres dépôts auxquels la victime a accès. C'est le principe même d'un ver informatique : il se réplique sans intervention humaine supplémentaire.

Le résultat, en quelques heures : 73 dépôts appartenant aux organisations GitHub Azure, Azure-Samples, Microsoft et MicrosoftDocs sont compromis. L'impact opérationnel est immédiat : les pipelines CI/CD — les chaînes d'intégration et de déploiement continu qui permettent aux équipes de livrer du logiciel automatiquement — tombent en panne. Notamment ceux qui dépendent de Azure/functions-action, une brique utilisée dans d'innombrables projets cloud.

Pourquoi les outils IA sont devenus le vecteur idéal

Pour comprendre la mécanique de Miasma, il faut s'arrêter sur ce qui rend les outils de développement assistés par IA fondamentalement différents des éditeurs de code traditionnels.

Un outil comme Claude Code, Cursor ou Gemini CLI ne se contente pas de lire vos fichiers. Il les analyse, en extrait du contexte, les envoie partiellement vers des serveurs distants pour générer des suggestions, et — surtout — il a un accès élargi à votre système de fichiers local, à vos variables d'environnement, à vos configurations. C'est cette richesse d'accès qui fait leur valeur : ils sont efficaces précisément parce qu'ils voient tout.

Mais cette même richesse d'accès devient une surface d'attaque considérable si un dépôt compromis sait comment en tirer parti. Le payload de Miasma est conçu pour s'intégrer dans les flux de traitement de ces outils. Il ne demande pas d'autorisation. Il ne déclenche pas d'alerte visible. Il se fond dans les opérations normales de l'outil IA, qui lit le dépôt, exécute ou analyse du code, et sans le savoir, transmet des données sensibles vers l'extérieur.

Le modèle de confiance mis à rude épreuve

Il y a ici une faille structurelle que Miasma met en lumière de façon brutale. Les développeurs font confiance aux dépôts officiels de Microsoft. C'est raisonnable : ce sont des projets maintenus par des équipes professionnelles, revus, audités. Cette confiance est légitime.

Les outils IA, de leur côté, font confiance au code qu'on leur soumet. Ils ne font pas la distinction entre un fichier de configuration légitime et un fichier de configuration qui contient des instructions malveillantes dissimulées. Leur rôle n'est pas (encore) d'auditer la sécurité de chaque ligne avant de l'analyser.

Miasma a exploité l'intersection de ces deux confiances. Un dépôt de confiance, analysé par un outil de confiance, dans un environnement où personne ne pense à douter. Le résultat est une attaque qui, sur le papier, ne devrait pas fonctionner — et qui pourtant a fonctionné à très grande échelle.

L'anatomie d'une supply chain attack moderne

L'expression "supply chain attack" — attaque par la chaîne d'approvisionnement — désigne une catégorie d'attaques où l'on ne cible pas directement la victime finale, mais un maillon intermédiaire dont elle dépend. Dans le développement logiciel, ce maillon, c'est souvent une dépendance, une librairie, un outil partagé.

Miasma en est une illustration exemplaire, avec une mécanique en plusieurs étapes qu'il est utile de décomposer :

Ce qui distingue Miasma des supply chain attacks précédentes — SolarWinds en 2020, XZ Utils en 2024 — c'est la vitesse de propagation. Un ver qui se réplique automatiquement via des credentials valides n'a pas besoin d'attendre qu'un humain télécharge une mise à jour. Il agit à la vitesse des API.

Les 73 dépôts Microsoft : ce que ça représente concrètement

73 dépôts, ce n'est pas un chiffre abstrait. Les organisations GitHub touchées — Azure, Azure-Samples, Microsoft, MicrosoftDocs — hébergent des projets critiques sur lesquels s'appuient des millions de développeurs dans le monde entier.

Azure/functions-action, par exemple, est une GitHub Action utilisée pour déployer des Azure Functions directement depuis un pipeline CI/CD. Des centaines de milliers de workflows automatisés l'intègrent. Quand ce dépôt est compromis, ce n'est pas seulement le dépôt lui-même qui pose problème — c'est potentiellement chaque pipeline qui le référence et qui pourrait, lors de sa prochaine exécution, télécharger et exécuter du code malveillant.

L'interruption des pipelines CI/CD constatée dans les heures suivant l'attaque n'est que la partie visible. La partie invisible, c'est l'étendue réelle de la collecte de credentials effectuée avant que l'attaque ne soit détectée et contenue.

Pourquoi la détection prend du temps

Une des raisons pour lesquelles ce type d'attaque est particulièrement redoutable, c'est la difficulté à la détecter rapidement. Un commit dans un dépôt actif, avec des credentials valides, ressemble à n'importe quel autre commit. Les systèmes de surveillance classiques cherchent des comportements anormaux — un commit légitime, techniquement, n'en est pas un.

Pour identifier Miasma, il a fallu analyser le contenu du commit, comprendre son comportement potentiel dans un environnement IA, puis remonter la chaîne de propagation. Ce travail forensique — d'investigation numérique — prend des heures, parfois des jours. Pendant ce temps, le ver continue de tourner.

Ce que Miasma révèle sur la sécurité des environnements de développement IA

L'industrie du développement logiciel a adopté les outils IA à une vitesse remarquable. Claude Code, Cursor, Gemini CLI — ces outils sont désormais dans le quotidien de millions de développeurs. Leur efficacité n'est pas en cause. Leur modèle de sécurité, lui, mérite qu'on s'y attarde.

Ces outils ont été conçus avec un objectif principal : être utiles. Ils analysent du code, proposent des corrections, génèrent des fonctions entières. Pour faire tout cela, ils ont besoin d'accès. Et cet accès, accordé avec enthousiasme par des équipes désireuses de productivité, n'a pas toujours été encadré par des politiques de sécurité adaptées.

Miasma n'est pas un dysfonctionnement de ces outils. C'est une exploitation de leur design. La question n'est pas "ces outils sont-ils dangereux ?" mais "comment les intégrer dans un environnement où le code qu'on leur soumet pourrait être malveillant ?"

C'est une question que peu d'organisations s'étaient posée sérieusement avant le 5 juin 2026. Miasma l'impose désormais à l'agenda de toutes les équipes de sécurité.

Ce que l'on peut attendre comme réponse de l'industrie

Microsoft n'a pas tardé à réagir : les dépôts compromis ont été nettoyés, les pipelines affectés notifiés, et les équipes de sécurité ont commencé le travail d'évaluation de l'impact réel de la collecte de credentials. Mais la réponse d'urgence ne suffit pas.

Plusieurs chantiers s'imposent à l'ensemble de l'industrie. Les éditeurs d'outils IA — Anthropic pour Claude Code, Google pour Gemini CLI, Anysphere pour Cursor — vont devoir repenser leurs modèles de sandboxing. Un outil qui analyse du code externe doit pouvoir le faire dans un contexte isolé, sans accès aux secrets de l'environnement de développement.

GitHub de son côté devra vraisemblablement renforcer les mécanismes de détection comportementale sur les commits : analyser non seulement qui pousse du code, mais ce que ce code fait, et dans quel contexte il est susceptible de s'exécuter.

Il faut aussi s'attendre à ce que Miasma ne soit pas un incident isolé. C'est une démonstration de faisabilité. D'autres acteurs malveillants ont désormais un modèle d'attaque éprouvé, qui combine la compromission de credentials légitimes, l'injection dans des dépôts de confiance, et l'exploitation des outils IA comme vecteurs de propagation. Ce modèle va être réutilisé, adapté, amélioré.

Notre lecture de l'événement

Miasma est une attaque intelligente, pas parce qu'elle exploite une vulnérabilité zero-day inédite dans un logiciel, mais parce qu'elle exploite un angle mort organisationnel et culturel. La transition vers le développement IA-assisté a été rapide — peut-être trop rapide pour que les pratiques de sécurité suivent au même rythme.

Les développeurs qui utilisent Claude Code ou Cursor au quotidien ne pensent généralement pas à ces outils comme à des surfaces d'attaque. Ils y pensent comme à des assistants. Et c'est précisément ce cadre mental qui crée la vulnérabilité : on ne sécurise pas ce qu'on ne perçoit pas comme un risque.

Il ne s'agit pas d'abandonner ces outils — ils sont genuinement productifs et leur adoption va continuer de croître. Il s'agit d'adopter, avec eux, une posture de sécurité adaptée à leur réalité technique. Ce qui signifie : isoler les accès, limiter les permissions, vérifier les sources, et traiter le code externe — même celui issu de dépôts réputés fiables — avec la prudence que l'on réserve habituellement aux entrées utilisateur.

La confiance est une ressource précieuse dans l'écosystème open source. Miasma nous rappelle qu'elle doit être vérifiable, pas seulement ressentie.