GitHub a désactivé 73 dépôts officiels de Microsoft le 5 juin 2026. L’incident a impliqué les organisations Azure et Durable Task et a exposé une vulnérabilité critique dans le flux de travail du développement moderne: ouvrir du code dans des outils tels que Claude Code, Gemini CLI, Cursor ou VS Code peut compromettre une machine entière, sans aucun clic suspect, sans aucun téléchargement manuel.
Par conséquent, comprendre ce qui s’est passé ici n’est pas qu’une curiosité technique. C’est une question de sécurité opérationnelle pour tout développeur qui travaille avec des dépôts externes.
GitHub, d’abord, le vecteur d’attaque : ce n’était pas le code, ce sont les fichiers de configuration
Un contributeur doté de credentials déjà compromis a envoyé un commit au dépôt Azure/durabletask. Jusque-là, rien d’inhabituel dans la routine de contribution open source. Mais le commit n’altérait pas la logique métier ni ne corrigeait des bugs. Au contraire, il ajoutait cinq fichiers de configuration que les outils de développement exécutent automatiquement lors de l’ouverture du projet.
Le résultat était clair: un exécutable malveillant de 4,6 Mo tournait silencieusement en arrière-plan. Pas de pop-up, pas d’avis, aucune interaction de l’utilisateur.
GitHub : ce que le malware collectait, et pourquoi c’est particulièrement grave pour les développeurs
Dès activation, le programme parcourait la machine à la recherche d’identifiants AWS, Azure et Google Cloud, de jetons GitHub, de clés SSH et de variables d’environnement. De plus, il lisait aussi l’historique du terminal.
Pour la plupart des utilisateurs ordinaires, cela serait grave. Pour un développeur, toutefois, c’est catastrophique. Un dev dispose généralement d’accès à des serveurs de production, des pipelines CI/CD, des bases de données et des systèmes internes des clients. Avec ces identifiants en main, l’attaquant devient, effectivement, le développeur.
Pourquoi l’attaque de juin a été possible : la leçon des identifiants non rotativés
Cet incident de juin ne s’est pas produit par hasard. En mai, le même compte compromis avait été utilisé pour publier trois versions malveillantes du paquet durabletask sur PyPI. Le paquet est téléchargé plus de 400 000 fois par mois, ce qui augmente considérablement l’étendue potentielle de l’impact.
Apparemment, Microsoft n’avait pas complètement rotationné les identifiants du compte après l’incident de mai. Cela a permis à l’attaquant de réutiliser le même accès quelques semaines plus tard.
Autrement dit: la faille n’était pas seulement technique. Elle était aussi procédurale.
Le ver Miasma et le groupe derrière le code
Le groupe TeamPCP a revendiqué la responsabilité du Mini Shai-Hulud, le ver précurseur direct de Miasma. Le groupe a un historique documenté d’attaques contre des paquets open source en 2025 et 2026, avec des victimes incluant Mistral AI, LiteLLM et des centaines de paquets npm.
Ce qui est le plus préoccupant, toutefois, est que le code du Mini Shai-Hulud a été publié ouvertement. Cela signifie que toute personne avec des connaissances techniques suffisantes peut dériver de nouvelles variantes. Déterminer si le Miasma est l’œuvre du même groupe ou de quelqu’un qui a profité du code disponible est donc extrêmement difficile.
L’effet cascade : pipelines cassés en moins d’une heure
L’un des dépôts touchés était Azure/functions-action, utilisé par les développeurs pour automatiser les déploiements dans le cloud Azure. Avec la désactivation, tous les processus dépendant de ce dépôt se sont arrêtés simultanément.
En quelques heures, le forum d’assistance de Microsoft enregistrait déjà plus de 20 témoignages de pipelines entièrement cassés. Il est donc évident à quel point la chaîne de dépendances d’une équipe de développement est vulnérable à une unique faille compromise.
Ce que vous devez faire maintenant, et ce qui changerait dans votre flux de travail GitHub
Si vous avez cloné un dépôt affecté et que vous l’avez ouvert dans un outil IA ou un éditeur avec extensions actives après le 2 juin, traitez la machine comme compromise et effectuez la rotation de toutes les identifiants stockés dessus.
Pour réduire l’exposition à l’avenir, certaines pratiques directes font la différence :
Verrouillez les versions des paquets que vous utilisez. Les versions flottantes sont une porte ouverte à des substitutions malveillantes.
Passez en revue régulièrement les commits récents dans les dépôts que vous utilisez, en particulier ceux qui ajoutent des fichiers de configuration comme .claude/, .gemini/ ou .vscode/tasks.json. Ces fichiers sont exécutés automatiquement par des outils populaires et, pour cette raison, constituent des vecteurs d’attaque très efficaces.
Examinez également la politique de rotation des identifiants de votre équipe. Le cas de Microsoft démontre qu’un incident sans rotation adéquate finit par être la porte d’entrée de la prochaine attaque.
Le modèle de confiance implicite dans l’open source est sous pression
Pendant longtemps, l’écosystème open source a fonctionné sur une prémisse de confiance: dépôts d’organisations connues, paquets largement utilisés et comptes de contributeurs établis étaient traités comme sûrs par défaut.
Le ver Miasma, ainsi que des attaques antérieures à la chaîne d’approvisionnement logicielle, démontre que cette prémisse doit être révisée. Par conséquent, la sécurité d’un projet ne dépend pas seulement du code que vous écrivez, mais aussi de chaque dépendance, chaque configuration et chaque compte ayant accès au dépôt.
Dans le modèle actuel de développement, où des outils d’IA lisent et exécutent automatiquement le contexte des dépôts, le périmètre de sécurité s’est élargi de manière significative. Ouvrir un dépôt est devenu un acte dont les implications de sécurité vont au-delà de la machine locale.
La question qui demeure est: votre flux de travail en tient-il compte ?
Suivez notre profil sur Instagram !
