Miasma Worm Disables Microsoft GitHub Repos and Exposes a New CI/CD Weak Point

The most important part of the latest Miasma incident is not just that GitHub disabled a large block of Microsoft repositories. It is that the suspected worm moved the point of execution closer to the developer’s workspace: the repo could be safe to clone, but dangerous to open in the wrong tool.

GitHub disabled 73 repositories across Microsoft-related GitHub organizations after a malicious commit was pushed to Azure/durabletask, according to StepSecurity’s forensic write-up. The Register reported that the takedown quickly broke CI/CD workflows, especially jobs that referenced Azure/functions-action.

What happened

StepSecurity says the June 5 incident began with a commit to Azure/durabletask that added tool configuration files rather than ordinary source-code changes. The commit was backdated, included a [skip ci] marker, and planted a payload path under .github/setup.js, according to the same StepSecurity analysis.

From install hooks to folder-open execution

The notable shift is execution surface. Previous supply-chain defenses often focus on package install hooks, registry publishes, and CI pipelines. In this case, StepSecurity says the planted files targeted Claude Code session hooks, Gemini CLI session hooks, Cursor rules, and VS Code tasks that can run when a folder is opened or when an agent is instructed to initialize a project.

That makes editor and AI-agent configuration files part of the software supply chain. A repository can carry instructions that do not look like application code but still influence what a developer’s tools execute.

Why CI/CD teams felt it immediately

The impact was visible because one of the disabled repositories was Azure/functions-action, an official GitHub Action used to deploy Azure Functions. A Microsoft Learn Q&A thread showed developers reporting broken deployment workflows while the repo was unavailable.

Mutable tags made the outage contagious

The incident also exposed a common dependency-management weakness: workflows that call an action by a mutable tag such as @v1 depend on the repository and tag resolving at runtime. When the repository disappears, the pipeline fails even if the user’s own code did not change.

Pinning critical GitHub Actions to reviewed commit SHAs does not prevent every supply-chain failure, but it makes dependency drift more explicit and gives teams a clearer audit trail when a project is disabled, renamed, or compromised.

What defenders should audit now

The broader Miasma campaign has been described as a credential-harvesting worm that targets cloud keys, GitHub tokens, CI secrets, Kubernetes material, and developer-tool configurations. StepSecurity’s separate analysis of the npm wave describes a self-spreading campaign that abused binding.gyp and targeted multiple cloud and developer ecosystems. That report is useful context for why a repository-level attack matters beyond one disabled action.

Audit editor and agent config as code

Security reviews should treat .claude/, .gemini/, .cursor/, .vscode/tasks.json, and hidden setup scripts as executable policy, not harmless workspace clutter. Unexpected changes to those paths deserve the same scrutiny as a new build script or package lifecycle hook.

Rotate first, investigate second

If a developer opened a suspicious repo in an agentic coding tool or IDE, the safer assumption is that accessible credentials may have been exposed. Rotate GitHub tokens, cloud credentials, package-publishing tokens, SSH keys, and CI secrets before trying to prove which token was used.

Harden CI/CD dependency hygiene

For production pipelines, pin third-party actions to SHAs, require review on workflow and tool-config changes, monitor outbound CI traffic, and block direct pushes to protected branches. The Miasma story is a reminder that modern supply-chain attacks are not limited to package managers; they can travel through the developer experience itself.

Featured image: “Tests” by Lachlan Hardy, licensed under CC BY 2.0.