Miasma Worm Attack: Microsoft Hacked to Deliver Malware to Claude and Gemini Users
What really happened, how the Miasma worm spreads via AI coding agents, and how to protect your credentials.
The 15-Second TL;DR
On June 5, 2026, a self-replicating worm known as Miasma successfully compromised 73 of Microsoft's own GitHub repositories across four major organizations, Azure, Azure-Samples, Microsoft, and MicrosoftDocs.
The attack worked like this: hackers planted malicious configuration files inside legitimate Microsoft repositories. But here's where it gets scary. A developer didn't need to run any suspicious code or click any shady links. They just needed to clone an affected repo and open it in an AI coding agent, like Claude Code, Gemini CLI, or Cursor, and the malware would execute automatically, harvesting every cloud credential on their machine. No code execution required. Just open the project. That's it.
GitHub disabled all 73 repositories in a staggering 105 seconds. But for developers who cloned those repos before the takedown, the damage may already be done.
This was the second supply-chain attack on Microsoft in as many months, and it signals a terrifying new chapter in software security: AI coding agents are no longer just tools. They're now attack vectors.
Anatomy of the Attack → How a Supply Chain Breach Paved the Way
Let's break this down step by step, because understanding the mechanics is the first step toward protecting yourself.
The Compromised Contributor Account
It all started with a contributor account that had legitimate write access to Microsoft's GitHub organizations. According to security researchers from StepSecurity, this account had likely been compromised in an earlier wave of the Miasma campaign. Hackers from the group TeamPCP (more on them in a moment) used this stolen access to push a malicious commit to the Azure/durabletask repository.
Think of it like this: imagine a trusted employee at a bank gets their security badge stolen. The thief walks into the bank, badges in, and starts making legitimate-looking changes to the vault's access logs. Nothing looks suspicious because the credentials are real.
The Malicious Commit to Azure DurableTask
The durabletask repository is not some obscure side project. It's a Microsoft development framework for building fault-tolerant workflows that receives roughly 400,000 downloads per month. When the hackers pushed their malicious commit, they weren't targeting a random repo, they were poisoning the well at the heart of Microsoft's Azure automation ecosystem.
That single compromised commit triggered a chain reaction. Within minutes, the Miasma worm had autonomously pushed malicious code to 73 different Microsoft repositories across the Azure, Azure-Samples, Microsoft, and MicrosoftDocs organizations.
The Miasma Worm → A Self-Replicating Credential Stealer
Miasma is the name security researchers gave to this particular variant of malware. But it's helpful to understand where it came from.
From Shai-Hulud to Miasma: The Evolution of a Worm
The original Shai-Hulud worm, named after the giant sandworms from Dune, appeared in September 2025 as the first self-replicating malware observed in the npm ecosystem. TeamPCP, the threat actor behind these attacks, eventually open-sourced the toolkit, effectively handing the keys to the kingdom to anyone with malicious intent.
Miasma is essentially a clone of TeamPCP's Mini Shai-Hulud toolkit, with cosmetic changes. References to Dune were replaced with Greek mythology, but the underlying credential-stealing functionality remained intact.
Phantom Gyp and the 157-Byte Payload
Here's where things get technically fascinating (and terrifying). Earlier versions of the worm used standard npm lifecycle scripts like preinstall and postinstall — which most security scanners now monitor. But Miasma v2 introduced a technique called Phantom Gyp. Instead of using lifecycle scripts, it ships a ~157-byte binding.gyp file containing a command-substitution action that triggers code execution during npm install.
It's a bit like a thief learning that security cameras are watching the front door, so they sneak in through a window that nobody thought to monitor. The window is always there, but nobody ever looked.
Once the worm runs, it steals npm tokens, enumerates every package the compromised maintainer owns, injects the payload into each one, and republishes them with forged SLSA provenance attestations signed by Sigstore. That means even tools designed to verify supply-chain integrity see the malicious packages as legitimate updates.
AI Coding Agents as Attack Vectors → When Trusted Tools Backfire
This is the part that keeps me up at night, and it should keep you up, too.
No Code Execution Required: Just Opening a Repo Triggers the Attack
The Miasma worm plants backdoor configuration files inside compromised repositories, specifically .claude/settings.json, .gemini/settings.json, and Cursor config directories. These files execute a credential-harvesting payload the moment a developer opens the project in Claude Code, Gemini CLI, or Cursor.
A developer never runs a single line of malicious code. They never approve a suspicious permission. They just open a project they trust, perhaps from Microsoft's official GitHub, and within seconds, every cloud credential on their machine is being exfiltrated to an attacker-controlled server.
A developer who never runs a single line of the project's actual code can still have every cloud credential on their machine stolen.
Targeted Tools: Claude Code, Gemini CLI, Cursor, and VS Code
The worm is designed to execute automatically through five developer tools:
- Claude Code (Anthropic's AI coding agent)
- Gemini CLI (Google's AI command-line tool)
- Cursor (The popular AI-powered code editor)
- VS Code (with AI extensions)
- npm test script
Once triggered, the Bun-based worm harvests credentials for AWS, Azure, GCP, Kubernetes, npm, GitHub, password managers, and over 90 additional developer tool configurations. It then uses those stolen tokens to commit itself into any repository the victim can write to, spreading autonomously across the ecosystem.
Microsoft's Response → 73 Repositories Disabled in 105 Seconds
When Microsoft realized what was happening, they took action, fast.
The Unusual Step of Self-Shutdown
Microsoft did something highly unusual: it shut down dozens of its own GitHub repositories. GitHub staff disabled 73 Microsoft repositories across four GitHub organizations in a 105-second sweep on June 5. The disabled repositories included 49 related to Azure, the entire Durable Task family, the azure-search-openai-demo (Microsoft's most-cloned RAG starter app), and various AI sample applications.
At the time of writing, those repositories display a message: "This repository has been disabled. Access to this repository has been disabled by GitHub Staff due to a violation of GitHub's terms of service".
Here's the frustrating part. Microsoft's initial public statement downplayed the severity. An email to 404 Media stated only: "We have temporarily removed some repositories as we investigate potential malicious content". The message didn't warn developers who had already cloned the affected repos that their machines might be compromised.
The DurableTask Connection: A Wound That Never Healed
This wasn't Microsoft's first run-in with TeamPCP. In mid-May, the same threat actor compromised Microsoft's durabletask Python SDK on PyPI, releasing three malicious versions. That compromise executed a 28 KB payload that steals credentials from AWS, Azure, GCP, Kubernetes, password managers, and over 90 developer tool configurations.
Security researcher Paul McCarty put it bluntly: "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".
Who Is Behind the Attack? → The TeamPCP Threat Actor
The attack has been linked to a threat actor tracked as TeamPCP (also known as Replicating Marauder, TGR-CRI-1135, and UNC6780). This group has performed a wealth of supply chain attacks in the first half of 2026, impacting hundreds of organizations.
What makes TeamPCP particularly dangerous is their willingness to open-source their tooling. By releasing Mini Shai-Hulud publicly, they've enabled copycats and amplified the threat across the entire open-source ecosystem.
Security firm Cloudsmith noted: "The genius of this Miasma worm lies in how it adhered to legitimate workflows. It does not exploit any software vulnerability in GitHub or npm. Instead, 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 must be safe, that assumption is now dangerously obsolete.
Immediate Actions for Developers → How to Secure Your Credentials
Okay, we've covered the scary part. Now let's talk about what you need to do right now.
Step 1: Check Your Activity and Rotate Tokens
If you've cloned any Microsoft GitHub repositories, especially those related to Azure, DurableTask, or AI sample apps, between mid-May and June 5, assume your environment may be compromised. Immediately rotate all cloud credentials: AWS, Azure, GCP, Kubernetes, npm, and GitHub tokens.
Step 2: Lock Down Personal Access Tokens (PATs) and OIDC
The Miasma worm specifically targets OIDC (OpenID-Connect) token credentials used in SLSA provenance attestation. Review your GitHub Actions settings, audit which tokens have access to which repositories, and revoke any that aren't absolutely necessary. Consider using fine-grained PATs with the principle of least privilege, only the permissions required, nothing more.
Step 3: Audit Cloned Repositories from the Affected Period
Scan any repositories you cloned from Microsoft's GitHub organizations between May 19 and June 5, 2026. Look for unexpected .claude/settings.json, .gemini/settings.json, or binding.gyp files. If you find them, assume compromise and rotate credentials stored on that machine.
Step 4: Implement Third-Party Security Scanners
The Miasma attack demonstrated that even cryptographically signed packages from verified maintainers cannot be trusted blindly. Tools like SafeDep found 123 repositories across dozens of accounts already carrying the Miasma hook pattern. Consider implementing third-party supply-chain security scanning tools that can detect behavioral anomalies, not just signature verification.
Why This Attack Is a Turning Point
This attack signals a fundamental shift in the threat landscape. Supply chains are no longer passive targets, they're now contagion vectors. The Miasma worm is the first known case of a truly self-replicating supply chain attack that leveraged AI coding agents to camouflage its tracks.
And here's the pattern to watch. Between June 1 and June 5, Miasma hit in three waves, compromising 57 packages across 286+ malicious versions. This isn't a one-off, it's an accelerating campaign. SafeDep found that as of writing, more than 80 public repositories on GitHub carry the Miasma campaign's naming pattern.
The targeting of AI coding agents is a notable evolution. Developers increasingly rely on tools like Claude Code and Cursor to work with unfamiliar repositories. A worm that activates when an AI agent opens a project exploits a new behavior pattern that simply did not exist a year ago.
Frequently Asked Questions (FAQ)
Q: Was Microsoft's Azure cloud service hacked?
A: No, Microsoft's production Azure infrastructure was not compromised. The attack targeted GitHub repositories owned by Microsoft, not the cloud platform itself. However, CI/CD pipelines and GitHub Actions that relied on those repositories were disrupted.
Q: Should I stop using Claude Code and Gemini CLI?
A: Not necessarily, but exercise extreme caution when cloning unfamiliar repositories or pulling from the Microsoft GitHub organizations affected by this attack. The tools themselves aren't malware; they're being exploited as execution vectors.
Q: How can I tell if my machine was compromised?
A: Look for unexpected .claude/settings.json, .gemini/settings.json, or binding.gyp files in repositories you've cloned. Monitor for unusual outbound network connections or unexpected credential usage in your cloud dashboards.
Q: Did Microsoft fix the vulnerability?
A: Microsoft disabled the affected repositories, but the underlying trust-model vulnerability remains. A compromised maintainer with valid credentials can still push malicious updates to any package registry. The fix requires changes to how we authenticate and authorize in open-source ecosystems.
Q: Who else has been affected by the Miasma worm?
A: Beyond Microsoft, the worm has compromised Red Hat npm packages (32 packages compromised on June 1), TanStack, Mistral AI, UiPath packages, and is now pushing directly to source repositories.
How to Stay Safe in an Evolving Threat
This is the part where I could tell you everything is fine and to go back to your work. But that wouldn't be honest.
The Miasma attack is a wake-up call. The trust model that has underpinned open-source software for decades, the assumption that a signed package from a verified maintainer is safe, is no longer sufficient. Attackers are now actively compromising the keys and the maintainers, then acting exactly like legitimate publishers.
But here's the good news: awareness is protection. You're reading this now, which means you're ahead of the curve. You understand the threat. And with that understanding comes the ability to protect yourself.
Check your credentials. Audit your dependencies. Rotate your tokens. And whatever you do, don't assume that just because a package comes from Microsoft, or any trusted source, that it's safe.
The tools we trust are evolving. The threats targeting them are evolving, too. Your security practices need to keep up.