Miasma Worm Turns Microsoft GitHub Repositories and AI Coding Agents into Supply Chain Risk

The Miasma supply chain campaign has reportedly reached 73 repositories across four Microsoft GitHub organizations: Azure, Azure-Samples, Microsoft, and MicrosoftDocs. The Hacker News, citing OpenSourceMalware research, reported that GitHub disabled access to the affected repositories on June 6, 2026. The list includes projects connected to Azure Functions, Durable Task, connectors, documentation, Windows drivers, and AI-related samples. The number is significant, but the more important lesson is how the worm appears to spread: through trusted identities, repository access, developer workflows, and legitimate publishing channels rather than a single GitHub platform vulnerability.

Miasma is assessed by researchers as an evolving variant of Mini Shai-Hulud, a self-replicating software supply chain worm associated with TeamPCP. Akamai documented the May 2026 wave as an escalation from earlier token-stealing npm attacks. In that campaign, a GitHub Actions cache-poisoning path and npm's OpenID Connect publishing flow were abused to place malicious releases behind valid automation and attestations. The worm then harvested credentials, enumerated reachable repositories and packages, and continued propagating through the permissions it acquired.

That trust model is the central problem. Package registries, source-control platforms, developers, and downstream consumers naturally treat authenticated maintainers and signed releases as stronger signals than anonymous uploads. Miasma turns those signals against the ecosystem. If the actor controls a maintainer account, CI token, repository workflow, or release identity, malicious activity can resemble normal publishing. Valid authentication proves which identity performed the action; it does not prove that the identity, workflow, or build environment was trustworthy at that moment.

The Microsoft repository incident also appears connected to an earlier wound. The durabletask PyPI package was reportedly compromised in May to deliver an information stealer on Linux systems. OpenSourceMalware researcher Paul McCarty noted that the latest repository takedowns included the wider Durable Task ecosystem across languages and supporting projects. That does not by itself prove the same credentials persisted for a month, but it raises an important incident-response question: did the earlier recovery revoke every credential, remove every persistence path, rebuild every affected workflow, and validate sibling repositories that shared trust?

A second development makes this campaign especially relevant to AI engineering teams. SafeDep reported that Miasma can bypass package registries and commit malicious content directly into source repositories. In the analyzed case, the repository changes were wired to execute through developer tools including Claude Code, Gemini CLI, Cursor, VS Code, and an npm test script. That creates a new activation surface: a developer may clone a repository, open it in an AI coding environment, and trigger repository-controlled configuration before performing a traditional package installation.

This is not evidence that AI coding agents are inherently malicious or uniquely vulnerable. It is evidence that agent configuration has become executable supply chain policy. Files under tool-specific directories, editor tasks, project hooks, test commands, and setup scripts can influence what runs when a repository is opened or analyzed. Security teams already review CI workflows and package lifecycle scripts; they now need equivalent controls for AI-agent instructions and tool hooks. A repository should not gain broad local execution rights merely because a developer asked an agent to understand the code.

For organizations that consumed or contributed to affected repositories, the first step is scope, not panic. Identify clones, forks, cached build artifacts, package releases, developer machines, CI runners, and internal mirrors associated with the affected projects during the relevant window. Preserve evidence before deleting suspicious files. Compare repository history against trusted upstream commits, inspect workflow and tool-configuration changes, and determine whether any developer or CI environment executed repository-controlled tasks.

The next step is credential containment. Rotate GitHub personal access tokens, fine-grained tokens, npm credentials, cloud credentials, SSH keys, signing keys, and CI secrets that were present on potentially affected developer systems or runners. Revoke active sessions where appropriate and review GitHub audit logs for new repositories, workflow modifications, branch changes, release activity, OIDC exchanges, deploy-key additions, and unusual token use. Rotation should not be treated as complete until persistence mechanisms are removed; otherwise the new credential may be collected again.

CI/CD recovery needs a clean-room mindset. Rebuild runners from trusted images instead of trying to clean them in place. Invalidate poisoned caches, review which pull-request workflows can write to shared caches, minimize workflow permissions, pin third-party actions, and separate untrusted fork execution from release credentials. OIDC improves secret handling, but its trust policy must bind tightly to expected repositories, branches, environments, and workflows. A short-lived token issued to a compromised workflow is still a valid attacker credential.

Developer endpoint controls need to catch up as well. Require review before repository-level agent hooks, editor tasks, or setup scripts execute. Consider opening unfamiliar or newly restored repositories inside disposable development containers with no production credentials. Separate personal coding environments from release environments, keep cloud and package-publishing tokens out of general developer shells, and monitor for abnormal processes launched by editors or AI coding tools. The goal is not to block agentic development. It is to stop repository content from silently deciding what an agent may execute.

Finally, maintainers should treat recovery as an ecosystem event. Notify downstream users, identify all packages and repositories reachable by the compromised identity, publish known-good commit and release information, and provide explicit credential-rotation guidance. Re-enable repositories only after account recovery, workflow review, secret rotation, artifact validation, and sibling-project assessment. The Miasma lesson is that one compromised package or repository is rarely the complete boundary when identities and automation span an organization.

HackWednesday's takeaway is straightforward: authenticated software is not automatically trustworthy software. Miasma reportedly propagated by blending into the legitimate mechanisms used to build, sign, publish, clone, and analyze code. Defenders must verify the identity, the workflow, the artifact, and the developer execution context together. AI coding agents add another powerful link to that chain, which means they need the same least-privilege, isolation, review, and telemetry expected from any other production-capable automation.