www.it-connect.fr
GitHub Temporarily Blocked 73 Official Microsoft Repositories to Protect Businesses
73 is the number of repositories temporarily disabled by GitHub within its official Microsoft organizations on GitHub: Azure, Azure-Samples, MicrosoftDocs, and Microsoft. The reason: a compromised repository that enabled the distribution of a password-stealing malware. Here is what we know about these events dating back to June 5.
An Attack Mitigated in 105 Seconds
On Friday, June 5, 2026, between 16:00:50 and 16:02:35 UTC, many Microsoft GitHub repositories were placed under a general alert. During this short time window, GitHub users could also see the following message: "This repository has been disabled. Access to this repository has been disabled by GitHub staff due to a violation of GitHub's terms of service."
In total, 73 repositories spread across four distinct organizations (Azure, Azure-Samples, microsoft and MicrosoftDocs) were disabled. The Azure organization was hit the hardest, with 49 repositories taken down, affecting the core of the Azure Functions ecosystem: the runtime (azure-functions-host), all language workers (Node.js, Python, Java, .NET, Go, PowerShell), distribution tools (azure-functions-core-tools), as well as binding extensions (Kafka, SQL, OpenAI, RabbitMQ).
Needless to say, this quickly impacted businesses using these services, especially Azure Functions. In fact, the incident affected the functions-action repository, the GitHub Action used to deploy code to Azure. In other words, it was a total outage for everyone using this solution.
A glitch? No. It is worse than that. GitHub blocking Microsoft repositories (its parent company) cannot be a mistake.
The Miasma Worm Lead
To understand the origin of this incident, we need to go back to May 19. On that date, the PyPI package durabletask (Microsoft's Azure Durable Task SDK, which records around 417,000 downloads per month) had been compromised.
Following this compromise, three malicious versions (tagged 1.4.1, 1.4.2, and 1.4.3) were injected within 35 minutes using GitHub Actions secrets stolen by the TeamPCP attacker group (which has made headlines several times in recent months).
And here we are again with another incident related to Durable Task, with the simultaneous disappearance of the Azure/durabletask repository and all of its software variants stored in the microsoft organization (.NET, Go, Java, JS, MSSQL, Netherite, etc.). This suggests that the access keys compromised in May were probably never fully revoked by Microsoft.
This malicious activity would be linked to the TeamPCP group as well as the Mini Shai-Hulud campaign. It is believed to be the source of a malware called Miasma. It takes the form of a worm capable of spreading between GitHub repositories and specializes in exfiltrating authentication secrets.
Miasma's propagation pattern matches exactly the events that triggered GitHub's response. Once it steals credentials, the worm automatically creates public GitHub repositories titled "Miasma: The Spreading Blight" and drops the stolen secrets there as JSON files directly in the victim's account.
It is precisely this massive and highly suspicious creation of public repositories that triggered GitHub's automated filters. This led to the cleanup of dozens of repositories within Microsoft's own organizations. A necessary evil, since it could have led to the distribution of malware to thousands of companies...
The report published by OpenSourceMalware also states that Miasma is not on its first attack: "On June 1, Aikido and OX Security announced their first major discovery: Miasma, a rebranded version of Mini Shai-Hulud, which had infected 32 packages in the npm @redhat-cloud-services namespace."
Even so, the link between this Microsoft incident and Miasma still needs to be confirmed once the Redmond-based company has completed its investigation (assuming it communicates about it).
This incident should remind us more than ever to implement multi-day waiting periods before automatically fetching and applying package updates. By the way, Microsoft recently added a 2-hour delay in VS Code before applying extension updates.
