Supply Chain Security

73 Microsoft GitHub Repos Fall to Miasma Supply Chain Worm

June 7, 2026 · 8 min read · By William

The Scope of the Breach

Seventy-three repositories across Microsoft’s Azure, Azure-Samples, Microsoft, and MicrosoftDocs GitHub organizations have been disabled by GitHub Staff after the Miasma supply chain worm compromised them in a sustained campaign that came to light on June 5–6, 2026. The list includes azure-functions-host, the core runtime for Azure Functions, and the entire durabletask ecosystem — the .NET, Go, Java, JavaScript, MSSQL, Netherite, and protobuf implementations of Azure Durable Task Framework. Anyone who cloned these repos and opened them in an IDE or AI coding agent between late May and early June may have executed a credential-stealing payload. The Hacker News first reported the full scope, citing research from OpenSourceMalware.

The breach was confirmed when GitHub displayed a takedown notice on Azure/azure-functions-host: “Access to this repository has been disabled by GitHub Staff due to a violation of GitHub’s terms of service.” Security researcher Paul McCarty (6mile) noted that the durabletask repository had already been compromised by TeamPCP in May 2026, and the re-compromise of the same repo — plus every sibling repository in the Durable Task ecosystem — suggests the original credentials were never fully revoked. “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,” McCarty wrote.

How the Worm Propagates

Miasma is a variant of the Mini Shai-Hulud worm that TeamPCP publicly released in mid-May 2026. It has since mutated through multiple waves, refining its techniques with each iteration. The worm operates on a simple but devastating principle: compromise a maintainer’s credentials, use those credentials to push malicious code to downstream repos and packages, harvest credentials from anyone who installs or clones the poisoned code, and repeat.

The propagation has two arms. The registry arm publishes trojanized npm packages — 57 packages across 286+ versions in the most recent wave, using a technique SafeDep calls “Phantom Gyp”: hiding the trigger in a 157-byte binding.gyp file rather than the typical preinstall/postinstall lifecycle scripts that security tools monitor. The source-repo arm skips the registry entirely, pushing malicious commits directly to GitHub repositories with stolen PATs.

As of reporting, there are 13 repositories described as “Hades — The End for the Damned” and 82 repositories with Miasma-themed naming patterns on GitHub. The total number of compromised repos likely exceeds 120 across dozens of accounts.

AI Coding Agents as Attack Vector

The most novel aspect of this campaign is the targeting of AI coding agents. SafeDep’s technical analysis documents how a single commit to icflorescu/mantine-datatable and four sibling repositories planted a 4.3 MB payload runner wired to execute through five separate developer tools:

Claude Code — via a .claude/settings.json SessionStart hook that runs node .github/setup.js when an agent session opens
Gemini CLI — via an identical .gemini/settings.json hook
Cursor — via a .cursor/rules/setup.mdc project rule that instructs the agent to run the file as “required for proper IDE integration”
VS Code — via a .vscode/tasks.json task configured with "runOn": "folderOpen", requiring no agent at all
npm test — via a hijacked test script in package.json, catching CI pipelines

Cloning the repo is safe. Opening the folder is not. A developer who clones an affected repo to investigate a bug and opens it in VS Code — or starts Claude Code in the directory — runs the payload with zero further interaction. The dropper is an obfuscated JavaScript loader that uses a Caesar-shift decoder wrapping AES-128-GCM-encrypted payloads, fetched from hardcoded blobs. The final stage installs the Bun JavaScript runtime and loads a comprehensive credential harvester targeting AWS, Google Cloud, Azure, HashiCorp Vault, Docker, Kubernetes, GitHub Actions, npm, PyPI, RubyGems, SSH keys, password managers, and AI assistant configurations.

IronWorm: A Parallel Campaign

The same week, a distinct but related supply chain weapon surfaced. JFrog identified a Rust-based information stealer they codenamed IronWorm, published through a compromised npm account named “asteroiddao.” IronWorm targets 86 environment variables, credential files for OpenAI Codex, Anthropic Claude, Google Gemini, Cursor, AWS, Docker, Kubernetes, and Exodus cryptocurrency wallets. It also loads an eBPF kernel rootkit to hide its processes — though systems with kernel lockdown enabled resist this.

IronWorm’s self-propagation mechanism is especially notable in cloud contexts. In CI environments, it abuses npm’s Trusted Publishing flow to obtain short-lived OIDC tokens, then pushes poisoned package versions containing the malware back to the registry. It also swaps existing GitHub Actions workflows for one that harvests secrets and uploads them as build artifacts, eliminating the need for an external C2 server. Malicious commits were authored under the name “claude” to mimic Anthropic’s AI assistant. The malware stole the credentials of an organization member, then used them to push commits across nine GitHub organizations before vanishing.

Why Trust-Based Defences Failed

The worm does not exploit a vulnerability in npm, GitHub, or any CI/CD platform. It exploits the trust model those platforms are built on: the assumption that a package signed with a valid key and published by an authenticated maintainer is safe. FalconFeeds.io put it bluntly: “Shai-Hulud compromises the key and the maintainer, then proceeds to act exactly as a legitimate publisher would. From the registry’s perspective, every malicious publish event is indistinguishable from a routine update.” This is the same trust model failure we documented when GitHub was breached through a VS Code extension — stolen credentials weaponized through legitimate publishing channels.

Conventional supply chain security tools that rely on detecting suspicious lifecycle scripts — preinstall, postinstall, prepare — missed the Phantom Gyp variant entirely because it uses binding.gyp as the trigger. Tools that scan for known malicious hashes missed it because the payload is recompiled per wave. And tools that gate on package signatures saw valid signatures from legitimate accounts — the accounts were compromised, but the signatures were authentic.

The AI agent attack surface adds a new dimension. Most organizations do not monitor what their AI coding assistants execute. There is no equivalent of an EDR agent watching Claude Code’s shell commands or Cursor’s rule evaluations. The config files that trigger the payload — .claude/settings.json, .cursor/rules/setup.mdc, .vscode/tasks.json — are not on any security team’s radar because until now they were not considered an execution vector.

Immediate Actions for Cloud Teams

If your organization has cloned or forked any repository from the affected Microsoft GitHub organizations in the past 30 days, or if any developer has installed npm packages from the affected list, assume credential exposure and take the following steps:

Audit AI agent configurations. Check every cloned repo for unexpected .claude/settings.json, .gemini/settings.json, .cursor/rules/, or .vscode/tasks.json files that reference shell commands or Node.js scripts. These files should not exist unless your team created them deliberately.
Rotate all cloud credentials that may have been exposed on developer machines or in CI environments. This includes AWS access keys, Azure service principals, GCP service account keys, Kubernetes kubeconfig files, HashiCorp Vault tokens, and GitHub PATs. Prioritize credentials that had access to production environments or package registries. As we noted in our analysis of how stolen credentials cause 31% of all breaches, credential hygiene remains the single most impactful control.
Enable install script controls. Configure npm config set ignore-scripts true across all developer machines and CI runners. Use --ignore-scripts during dependency installation. This does not stop the Phantom Gyp variant but blocks the older lifecycle-script attacks.
Deploy AI agent monitoring. If your teams use Claude Code, Cursor, or similar tools, implement monitoring for the auto-run configuration directories. SafeDep’s GRYPH product and similar tools can monitor AI coding agent actions across projects and workflows.
Verify OIDC trusted publishers. Review GitHub Actions OIDC trust relationships for all your organizations. The @redhat-cloud-services compromise demonstrated that a single compromised publisher can poison 32 packages. Rotate OIDC tokens and enforce multi-reviewer policies on workflow changes.
Enable kernel lockdown on all Linux build runners and developer workstations. This single configuration change defeats IronWorm’s eBPF rootkit, making its process-hiding tricks fail and its sockets visible to standard monitoring tools.

The Miasma campaign represents a qualitative shift in supply chain attacks. The worm is no longer targeting just the package registry — it is targeting the developer’s entire toolchain, from the IDE to the AI assistant to the CI pipeline. For teams still relying on SBOM and SLSA frameworks alone, this campaign is a wake-up call: provenance verification does not protect you when the publisher’s credentials are stolen. The trust model that underpins open-source software delivery was already strained. Miasma just proved it is broken. Defending against it requires treating every developer environment as an untrusted execution context, and every clone operation as a potential compromise vector.