A Worm Hit 73 Microsoft GitHub Repos and the Payload Fires When You Open the Repo in Claude Code. Your Coding Agent Is the New Attack Surface.

On June 5, a self-propagating supply-chain worm called Miasma pushed a malicious commit into the Azure/durabletask repository and spread to 73 Microsoft GitHub repositories across the Azure, Azure-Samples, Microsoft, and MicrosoftDocs organizations. GitHub caught it and disabled the affected repos in an automated sweep. Microsoft confirmed the breach, said it notified a small number of customers who may have pulled the bad content, and has been restoring repos as it reviews them.

That's the headline. Here's the part that should change how you work: the payload didn't fire on npm install. It fired when a developer opened the compromised repository in an AI coding tool (Claude Code, Cursor, Gemini CLI, VS Code) and the agent read the project's instruction files. The trigger wasn't running code. The trigger was an agent reading a repo. If you clone-and-open with an assistant attached, that's you.

How it worked

The attacker started with compromised contributor credentials, not a clever zero-day, just stolen access to accounts that could push commits. With that, they committed configuration files into the repo that contained instructions aimed squarely at AI coding agents. When a developer opened the project and let their agent index or act on it, the agent followed those instructions, ran a credential-harvesting payload, and exfiltrated cloud and developer-tool secrets. The worm then used the freshly stolen credentials to push itself into more repositories. That's the "self-propagating" part: every compromised developer became a vector for the next batch of repos.

So the chain is: stolen creds → poisoned config files → agent reads and acts → your secrets leave the building → your creds get the next victim. No install script required. No build step required. The malicious instruction lives in plain text that your agent is designed to read and obey.

Why this is different from an npm postinstall worm

We've covered a string of supply-chain attacks here, and most of them have the same shape: a malicious package runs a postinstall script during npm install or in CI, and that script does the damage. The defense is well-known: turn off install scripts, audit dependencies, scope CI tokens. Miasma is a different animal because the execution trigger moved.

The old model: code runs when your machine runs it. You could reason about that. Scripts run at install, at build, at test: discrete moments you could lock down. The new model: instructions "run" when an agent reads them. Your AI assistant is built to read every file in the repo, understand it, and act on it. A config file, a README, an AGENTS.md, a .cursorrules: these are not inert documentation to an agent. They're directives. And an agent that's been granted shell access, file access, and your environment variables is a very capable pair of hands for an attacker who can write a convincing instruction.

This is the same root cause as the agentjacking attacks: an AI coding agent will follow text it finds, and "text it finds" now includes whatever a stranger committed to a repo you cloned. The difference is that Miasma weaponized it through the supply chain at Microsoft scale, against real repos most of us have, at some point, opened without thinking.

The 10-minute Saturday check

I'd spend a few minutes this Saturday doing four things, in order of how much they help.

First, scope what your agent can actually touch. Most people run their coding agent with far more access than any single task needs: full filesystem, all environment variables, shell with no guardrails. Tighten it. If your agent doesn't need your AWS keys to refactor a component, don't run it in a shell where those keys are sitting in the environment.

Second, treat instruction files in cloned repos as untrusted code, because that's what they are now. AGENTS.md, .cursorrules, .clinerules, MCP config, any "context" file the agent auto-reads: when you pull down someone else's repo, read those yourself before you let an agent loose on the project. If a config file is telling the agent to run a setup command or fetch something, that's a red flag, not a convenience.

Third, rotate anything your agent could have seen if you've opened sketchy or unfamiliar repos lately. Cloud provider keys, GitHub tokens, npm tokens, API keys in .env files the agent had access to. Rotation is cheap; assuming you weren't exposed is expensive.

Fourth, run your agent in a sandbox for anything you didn't write. A container, a VM, a dev container: somewhere that a credential-harvesting payload finds an empty environment instead of your actual keys. This is the one change that turns "I opened a poisoned repo" from an incident into a non-event.

What I'd actually do

The convenient workflow (clone an interesting repo, open it, let the agent explore and explain it) is now a security decision, not a neutral one. I'm not going to stop doing it, because reading code with an agent is genuinely one of the best uses of these tools. But I've changed where I do it. Unknown repos get opened in a sandboxed dev container with no real credentials in reach. My actual keys live in environments my agent only touches for projects I trust and wrote.

That's the whole adjustment. Not "stop using coding agents," which is both impractical and the wrong lesson. The right lesson is that your agent reads everything and obeys a lot of it, so the question "what is allowed to be in front of my agent, and what can my agent reach" is now part of your threat model. Answer it once, set up a sandbox, and most of this risk goes away.

The honest counter-take

You could reasonably argue this is being over-covered. The actual victims here were people opening compromised Microsoft repos in the narrow window before GitHub's automated sweep disabled them, 105 seconds, by Microsoft's account, which is genuinely fast. The blast radius for any individual solo dev was probably small, and Microsoft says only a small number of customers downloaded the affected content. If you didn't pull one of those 73 repos in that window, nothing happened to you.

That's fair, and I'm not going to pretend Miasma personally hit most readers. But the mechanism is the point, not this one worm's body count. The attack surface it demonstrated (poison a repo's instruction files, wait for an agent to read them) is reusable, cheap, and doesn't depend on Microsoft. The next one won't be at a vendor GitHub can sweep in under two minutes. Setting up a sandbox and scoping your agent's access costs you one Saturday and protects you against the whole category, not just the incident that happened to make the news.

Author

Lukas

@lukcombinator

Sources

• Miasma Worm Hits 73 Microsoft GitHub Repositories in Major Supply Chain Attack — The Hacker News
• Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled — StepSecurity
• Microsoft's open source tools were hacked to steal passwords of AI developers — TechCrunch
• Microsoft investigates breach of open-source projects after malware injection — SC Media