"Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service," reads the message when attempting to access the "Azure/azure-functions-host" repository — one visible sign of a far wider disruption that has struck Microsoft code on GitHub.
Scope: 73 Microsoft repositories across four GitHub organizations
OpenSourceMalware reports that 73 Microsoft repositories across the Azure, Azure-Samples, Microsoft, and MicrosoftDocs GitHub organizations were impacted by the Miasma campaign. GitHub has disabled access to affected repositories; attempting to reach azure-functions-host produces the site-wide staff notice. A partial list of impacted repositories provided by OpenSourceMalware includes azure-search-openai-demo-purviewdatasecurity, Connectors-NET-LSP, Connectors-NET-SDK, durabletask, durabletask-dotnet, durabletask-go, durabletask-js, durabletask-mssql, functions-container-action, homebrew-functions, llm-fine-tuning, and windows-driver-docs.
Durable Task re-compromise and the TeamPCP link
Security researchers note a direct line from an earlier compromise to the current takedown. The durabletask PyPI package was infected last month by TeamPCP to deliver an information stealer on Linux systems. Paul McCarty (aka 6mile) highlighted the continuity: "When the repo at the root of last month's compromise is the hub of this month's takedown, that is not a coincidence - that is the same wound reopening. Whoever held those credentials in May plausibly never fully lost them." In short, the earlier incident that affected a packaged dependency now appears to have been leveraged to reach multiple sibling repositories across Microsoft organizations.
Miasma as a variant of Mini Shai-Hulud: evolution and naming patterns
Miasma is assessed to be a variant of the Mini Shai-Hulud worm that TeamPCP publicly released in mid-May 2026. The campaign has continued to mutate and refine its tactics while expanding the set of infected packages and repositories. The threat actors have stamped infected repositories with thematic descriptions — for example, "Miasma: The Spreading Blight", "Miasma : The Spreading Blight", "Miasma - The Spreading Blight", and "Hades - The End for the Damned." As of writing, investigators observed 13 repositories labeled "Hades - The End for the Damned" and 82 repositories using the three Miasma naming patterns.
Tactics: direct GitHub pushes, staged Bun loader, and AI-coding-agent triggers
Analysts from SafeDep documented a shift away from registry poisoning toward direct commits to source repositories. In one cluster, the actors pushed malicious code directly to icflorescu/mantine-datatable and four related repositories: mantine-contextmenu, next-server-actions-parallel, mantine-datatable-v6, and mantine-contextmenu-v6. SafeDep reported that the commit "added no dependencies. It planted a 4.3 MB payload runner and wired it to execute automatically through five developer tools: Claude Code, Gemini CLI, Cursor, VS Code, and the npm test script." The company described the dropper as "the same staged Bun loader, here repurposed for GitHub source-repo persistence rather than registry poisoning."
That method changes the attack vector: rather than waiting for users to install a poisoned package from a registry, the payload activates when a developer clones an affected repository and opens it in an AI coding agent or related developer tool.
Why the worm's mode of operation matters: trust, keys, and legitimate channels
Observers stress what makes Miasma especially difficult to stop: it operates within legitimate, authenticated publishing channels. FalconFeeds.io summarized the problem bluntly: "The worm's genius and the reason conventional defences largely failed is that it operates entirely within legitimate channels. It does not exploit a vulnerability in npm or GitHub. It exploits the trust model those platforms are built on: the assumption that if a package is signed with a valid key and published by an authenticated maintainer, it is safe." The actor Shai-Hulud, FalconFeeds.io said, "compromises the key and the maintainer, then proceeds to act exactly as a legitimate publisher would."
What this means for open-source maintainers, security teams, and enterprises
- Open-source maintainers: The durabletask case underscores a concrete concern over credential continuity; as Paul McCarty observed, access tied to the May compromise may not have been fully revoked. Maintainership and credential custody — particularly the keys and tokens that enable authenticated publishes and direct pushes — are at the center of the incident.
- Security teams and platform defenders: SafeDep's analysis points to a new trigger vector — AI coding agents and developer tools — that defenders will need to monitor. The campaign's movement away from registry poisoning to source-repo persistence changes detection and response priorities.
- Enterprises and procurement leaders: FalconFeeds.io's assessment frames a systemic risk: when threats can act through authenticated, routine publisher behavior, downstream users and customers are vulnerable to exponential propagation if a trusted maintainer or key is compromised.
The record in this incident is stark: a worm that evolved from a publicly released tool has repeatedly found fertile ground in authenticated channels, resurfacing in repositories tied to a prior compromise and triggering when developers open code in modern AI-driven tools. The central, concrete question the facts leave open is who retained access to the credentials after the May compromise and whether those access paths have been fully closed — a question that underpins both the current takedown and the risk of further propagation.
