73, c’est le nombre de dépôts désactivés temporairement par GitHub au sein de ses organisations officielles de Microsoft sur GitHub : Azure, Azure-Samples, MicrosoftDocs et Microsoft. La raison : la compromission d’un dépôt ayant permis la distribution d’un malware voleur de mots de passe. Voici ce que l’on sait sur ces faits remontant au 5 juin dernier.

Une attaque atténuée en 105 secondes

Le vendredi 5 juin 2026, entre 16:00:50 et 16:02:35 UTC, de nombreux dépôts GitHub de Microsoft sont passés en mode alerte générale. Pendant ce court intervalle de temps, les utilisateurs de GitHub ont d’ailleurs pu constater le message suivant : “Ce dépôt a été désactivé. L’accès à ce dépôt a été désactivé par le personnel de GitHub en raison d’une violation des conditions d’utilisation de GitHub.”

Au total, 73 dépôts répartis sur quatre organisations distinctes (, , et ) ont été désactivés. L’organisation a subi le plus lourd impact avec 49 dépôts supprimés, touchant le cœur de l’écosystème Azure Functions : le runtime (), tous les workers de langage (Node.js, Python, Java, .NET, Go, PowerShell), les outils de distribution () ainsi que les extensions de liaisons (Kafka, SQL, OpenAI, RabbitMQ).

Autant vous dire qu’il y a eu rapidement un impact pour les entreprises utilisatrices de ces services, en particulier Azure Functions. En effet, cet incident a impacté le dépôt , l’action GitHub utilisée pour déployer du code vers Azure. Autrement dit, c’était un blocage général pour tous ceux qui utilisent cette solution.

Une panne ? Non. C’est pire que ça. GitHub qui bloque les dépôts de Microsoft (sa maison mère), cela ne peut pas être une erreur.

La piste du ver Miasma

Pour comprendre l’origine de cet incident, il faut remonter au 19 mai dernier. À cette date, le paquet PyPI (le SDK Azure Durable Task de Microsoft, qui enregistre environ 417 000 téléchargements par mois) avait été compromis.

Suite à cette compromission, 3 versions malveillantes (estampillées 1.4.1, 1.4.2 et 1.4.3) avaient été injectées en l’espace de 35 minutes via des secrets GitHub Actions dérobés par le groupe d’attaquants TeamPCP (qui a souvent fait parler de lui ces derniers mois).

Et puis, là, nous revoilà une nouvelle fois avec un incident lié à Durable Task, avec la disparition simultanée du dépôt et de l’intégralité de ses variantes logicielles stockées dans l’organisation (.NET, Go, Java, JS, MSSQL, Netherite, etc.). Une situation qui laisse penser que les clés d’accès compromises en mai n’ont sans doute jamais été totalement révoquées par Microsoft.

Cette activité malveillante serait liée au groupe TeamPCP ainsi qu’à la campagne Mini Shai-Hulud. Elle serait à l’origine de la création d’un logiciel malveillant surnommé Miasma. Il se présente sous la forme d’un ver capable de se propager entre les dépôts GitHub et il est spécialisé dans l’exfiltration de secrets d’authentification.

Le mode de propagation de Miasma correspond précisément aux événements qui ont déclenché la réaction de GitHub. Une fois qu’il a dérobé des identifiants, le ver génère automatiquement des dépôts GitHub publics intitulés “Miasma: The Spreading Blight” et y dépose les secrets volés sous forme de fichiers JSON directement dans le compte de la victime.

C’est justement cette création en masse, et particulièrement suspecte, de dépôts publics qui a fait réagir les filtres automatiques de GitHub. C’est ce qui a mené au nettoyage de dizaines de dépôts au sein même des organisations de Microsoft. Un mal pour un bien, car cela aurait pu mener à la distribution d’un logiciel malveillant auprès de milliers d’entreprises…

Le rapport publié par OpenSourceMalware indique d’ailleurs que Miasma n’en est pas à sa première attaque : “Le 1er juin, Aikido et OX Security ont annoncé leur première découverte majeure : Miasma, une version rebaptisée de Mini Shai-Hulud, qui avait infecté 32 paquets dans l’espace de noms npm @redhat-cloud-services.”

Malgré tout, le lien entre cet incident Microsoft et Miasma reste à confirmer une fois que la firme de Redmond aura pu mener ses investigations (sous réserve qu’ils communiquent à ce sujet).

Cet incident doit plus que jamais nous inciter à instaurer des délais d’attente de plusieurs jours avant de récupérer et d’appliquer automatiquement les mises à jour de paquets. D’ailleurs, Microsoft a récemment ajouté un délai de 2 heures à VS Code avant d’appliquer les mises à jour d’extensions.