Miasma Worm Infects 73 Microsoft GitHub Repos via AI Coding…

The Miasma worm compromised 73 Microsoft repositories on GitHub in 105 seconds. The malware activates when a developer opens the repository in an IDE or AI coding agent — not at install — bypassing traditional supply-chain defenses.

On June 5, 2026, a malicious commit infected the Azure/durabletask repository on GitHub, triggering a compromise that spread to 73 repositories across four Microsoft organizations in 105 seconds. The Miasma worm does not target package managers or exploit technical vulnerabilities: it activates when a developer opens the repository in an IDE or AI coding agent, turning productivity tools into automatic execution vectors.

Key Takeaways

73 Microsoft repositories across four organizations (Azure, microsoft, Azure-Samples, MicrosoftDocs) were compromised by the Miasma worm
The 4.6 MB payload activates on Claude Code, Gemini CLI, Cursor, and VS Code via editor configuration files, not at clone or package install
GitHub disabled the repositories in 105 seconds (16:00:50–16:02:35 UTC), but the takedown broke CI/CD pipelines dependent on the official Azure/functions-action@v1
The compromised contributor account had already been used on May 19 to inject malicious versions of the durabletask package on PyPI, indicating persistent access that was not fully severed

The Editor Post-Install Vector: From setup.py to .cursor/rules

Traditional supply-chain attacks target installation hooks: preinstall, postinstall, setup.py. The Miasma worm inverts this logic. According to StepSecurity's reconstruction, cited by ICT Security Magazine, the malicious commit 5f456b8 adds five files — all configuration or payload, no source code modified — that trigger when the project folder is opened in the editor.

The four documented vectors are precise. Claude Code executes the payload via the SessionStart hook in .claude/settings.json. Gemini CLI uses an analogous mechanism in .gemini/settings.json. Cursor loads the code via prompt injection in .cursor/rules/setup.mdc. Visual Studio Code triggers the folderOpen task from .vscode/tasks.json. Each of these files is legitimate by definition: they are the same files developers use to automate local workflows.

"Instead of poisoning a package registry, the commit planted configuration files that trigger automatic code execution when a developer opens the repository in an AI coding tool or IDE" — Ashish Kurmi, StepSecurity (via The Hacker News)

The distinction is sharp: cloning the repository is safe; opening it in an editor or AI agent is far less so. This separation invalidates a deeply rooted assumption in developer practice and defense architectures.

How the SLSA Bypass Is Structural, Not Technical

SLSA signatures, attested provenance, and package-manager scans are useless here. The malicious commit comes from a legitimate maintainer account, compromised but technically authentic. The payload does not alter the build system or inject dependencies: it only modifies development-environment configuration files, outside the perimeter that supply-chain security tools monitor.

Commit 5f456b8 was backdated to 2020 and marked with the [skip ci] flag, which suppressed GitHub Actions' automatic verification pipeline. This combination — fake date and CI silencing — reduced the detection surface without violating any integrity control. The platform's trust model was exercised correctly: a maintainer with valid credentials pushed valid code; the code just happened to be malicious.

The question is not which tool failed, but which tool was tasked with watching. None was.

Timeline of Compromise and GitHub's Automated Response

The timestamps are precise. The commit was pushed on June 5, 2026. Between 16:00:50 and 16:02:35 UTC, GitHub's anti-abuse system disabled 73 repositories in an automated burst. StepSecurity verified via API that all returned 403 errors for terms-of-service violations.

Microsoft stated it had "temporarily removed some repositories as we investigate potential malicious content," but forensic evidence points to automatic platform enforcement, not manual removal. The disruption had downstream effects: the official Azure/functions-action@v1 was disabled, breaking CI/CD workflows that depended on it. More than twenty developers reported outages on Microsoft Learn threads.

The compromised account is the same one used on May 19 to upload malicious versions of the durabletask package to PyPI, with over 417,000 monthly downloads. According to OpenSourceMalware, cited by Security Affairs: "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." The continuity suggests credentials were not fully rotated after the first incident, though the dossier does not specify whether Microsoft performed a partial rotation or none at all.

The Actor and Payload: Collection and Exfiltration via GitHub Itself

Miasma is attributed to the TeamPCP group, already responsible for npm attacks against TanStack, @antv, and @redhat-cloud-services. The payload is a single obfuscated 4.6 MB JavaScript file (.github/setup.js) that harvests high-value credentials: GitHub and npm tokens, AWS keys, Azure service principals, GCP accounts, Kubernetes secrets.

Exfiltration goes to public GitHub repositories used as dead drops. The platform thus becomes C2 infrastructure: stolen data transits through legitimate channels, indistinguishable from ordinary traffic. ICT Security Magazine reports evocative descriptions of the dead-drop repositories as "Miasma: The Spreading Blight" and "Hades: The End for the Damned," though the dossier does not specify whether these names were observed in the Microsoft case or in the broader campaign.

What to Do Now

Converging sources indicate four priority areas for organizations that manage repositories or depend on GitHub Actions.

Treat AI/IDE configuration files as security artifacts. Files such as .claude/settings.json, .cursor/rules/, .vscode/tasks.json, and their equivalents must be included in pre-commit scans and code reviews, not dismissed as editor noise.

Verify dependencies on disabled GitHub Actions. Pipelines using Azure/functions-action@v1 or other actions in the affected repositories must be reviewed for disruption and for potential exposure to the malicious configuration files.

Isolate opening of external repositories. Open cloned repositories in sandboxes or containers without access to cloud credentials, disabling automatic execution of tasks and hooks until manual verification.

Audit maintainer accounts with historical access to PyPI and GitHub. The re-compromise pattern — same account, same project, different platforms — indicates that credential rotation after previous incidents must be verified with particular care.

Why This Attack Redefines the Perimeter

The novelty of Miasma is not in a technically sophisticated payload: it is in the redefinition of the boundary between safe and dangerous. For decades, software installation has been the line of demarcation. Cloning, downloading, opening read-only was considered neutral. The Miasma worm moves the danger to the moment of opening, when the AI agent or IDE builds the project context.

This has consequences for the entire industry. Provenance frameworks like SLSA are designed to ensure that built code matches verified source code. But when the source code itself contains instructions that self-execute on load, provenance becomes irrelevant: the code is authentic, the maintainer is authentic, the execution is legitimate, the result is catastrophic.

AI coding agents — Claude, Gemini, Cursor — are promoted as productivity accelerators and, implicitly, security accelerators: less manually written code, fewer errors. The Miasma case shows the flip side. The automation that makes opening a repository frictionless also makes malware execution invisible. The assistant meant to help write secure code becomes the vector that executes malicious code without asking permission.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references