🎧 Listen to this article: हिंदी · English · ಕನ್ನಡ · മലയാളം · ଓଡ଼ିଆ
The Day Microsoft's Repos Vanished
For a few minutes on June 5, 2026, some of Microsoft's most-cloned open-source projects simply disappeared. Seventy-three repositories, spread across four of the company's GitHub organizations — Azure, Azure-Samples, Microsoft, and MicrosoftDocs — were disabled inside a single 105-second window. That was not Microsoft cleaning house. It was GitHub's automated enforcement racing to contain a self-propagating worm called Miasma that had quietly turned the act of opening a repository into an act of handing over your credentials.
This matters now because the attack did not rely on you running a build, installing a dependency, or clicking a bad link. It weaponized the one tool developers increasingly trust to read code for them: the AI coding assistant. If you cloned an affected repo and opened it in Claude Code, Cursor, Gemini CLI, or VS Code, the malware could fire before you read a single line.
What Actually Happened
The entry point was a malicious commit pushed into Microsoft's Azure/durabletask repository. It did not add an obviously dangerous script. Instead, it planted AI-IDE configuration files — the kind of "run this on open" project settings that modern AI-assisted editors read automatically to set up their environment. The moment a developer opened the poisoned repository in an AI coding tool, those config files executed a credential-harvesting payload.
From there, Miasma behaved like a worm, not a one-off infection. It collected credentials for cloud platforms and developer tools from the compromised machine, then used those stolen credentials to authenticate as the victim and push itself into more repositories. Every new push looked, to GitHub and to package registries, like a routine update from a legitimate, authenticated maintainer. That is the whole trick.
Why This Was So Hard to Catch
Supply-chain security rests on a simple assumption: if a package is signed with a valid key and published by an authenticated maintainer, it is safe. Miasma — assessed to be a variant of the "Mini Shai-Hulud" worm that a group calling itself TeamPCP publicly released in mid-May 2026 — attacks that assumption directly. It compromises the key and the maintainer, then publishes exactly as a legitimate maintainer would. From the registry's point of view, there is nothing anomalous to flag. The malicious release is indistinguishable from an ordinary one.
The campaign did not stay on GitHub, either. It re-compromised the durabletask package on PyPI to deliver an information stealer on Linux. A related strain, nicknamed Hades, used Python .pth startup hooks to launch a Bun-powered JavaScript credential stealer every time a Python interpreter started — without the victim ever importing the malicious package. Simply having it present on the system was enough.
The AI-Assistant Angle Is the Real Story
Plenty of worms steal credentials. What makes Miasma a signpost for 2026 is how it triggers. AI coding assistants are designed to be helpful and autonomous: they read project files, set up environments, and run setup steps so you do not have to. That convenience is exactly the attack surface. A config file that says "run this to prepare the workspace" is trusted by the tool and, by extension, by you.
In other words, the worm did not need to fool a human into running code. It needed to fool the assistant the human had already told to act on their behalf. As we hand more of our workflow to autonomous tools, "I only cloned it, I didn't run anything" stops being a safe statement.
How Microsoft and GitHub Responded
GitHub's automated defenses disabled all 73 affected repositories in that now-infamous 105-second sweep — fast enough to limit spread, disruptive enough to break anyone depending on those projects mid-workflow. In the days that followed, Microsoft and GitHub restored some repositories while keeping others offline as the investigation continued. The Miasma source code itself briefly surfaced on GitHub in repositories named "Miasma-Open-Source-Release," pushed through compromised developer accounts — a reminder that once a worm is loose, its authors are not the only ones who can spread it.
Who Is at Risk
You should treat this as relevant if any of the following are true:
You use AI coding assistants that auto-run project configuration. Claude Code, Cursor, Gemini CLI, and VS Code with agentic extensions all read repo-level settings; that is the trigger path.
You cloned or opened Microsoft Azure/durabletask (or related) repos in early June 2026. Especially in an AI IDE, and especially on a machine holding cloud credentials.
You pull Python packages like durabletask from PyPI without pinning versions. A re-compromised release can reach you through a routine update.
If none of those apply, your direct exposure is low — but the pattern is the point, and it will be reused.
Step 1: Find Out If You Are Exposed
Reconstruct what your machine and tools actually did in early June 2026.
# Did you clone any of the affected Microsoft repos recently?
grep -rEl "durabletask|Azure-Samples" ~/ --include="*.git/config" 2>/dev/null
# Look for suspicious AI-IDE / editor config that runs on open
find . -maxdepth 3 \( -name "*.pth" -o -name ".cursorrules" -o -name "*.code-workspace" \) 2>/dev/null
# List recently installed Python packages and check for durabletask
pip list 2>/dev/null | grep -i durabletask
Any Python .pth file you did not create, or an AI-IDE config that invokes shell commands, deserves a hard look.
Step 2: Assume Credentials Are Burned — Rotate and Audit
If a machine opened an affected repo in an AI tool, treat every credential it held as compromised.
- Rotate cloud keys (Azure, AWS, GCP), GitHub/PAT tokens, npm/PyPI tokens, and SSH keys used on that machine.
- Audit your GitHub org for unexpected commits, new collaborators, or pushes you did not make — Miasma spread by pushing.
- Review package publishes from your accounts on npm and PyPI for releases you did not cut.
Rotating is unglamorous, but a worm that self-propagates via stolen credentials is only stopped when those credentials stop working.
Step 3: Harden Your AI-Assistant Workflow
The fix is not to abandon AI coding tools — it is to stop letting them auto-execute untrusted project files.
- Disable auto-run of repo-level config in your AI IDE; require explicit approval before any setup command runs.
- Open unfamiliar repos in a sandbox (a container or throwaway VM) with no real credentials present.
- Pin dependencies to known-good versions and verify checksums; do not let
latestpull a re-compromised release. - Keep secrets out of developer machines — use short-lived, scoped tokens and a secrets manager, so a stolen credential is low-value and quick to revoke.
Conclusion
The Miasma incident is not really a story about Microsoft. It is a story about the new shape of trust in software development. We have handed autonomous assistants the authority to read, configure, and run our projects — and an attacker who can plant one config file can borrow that authority. GitHub's 105-second takedown was an impressive containment, but the lesson is upstream of any single vendor: as your tools do more on your behalf, cloning is no longer harmless. Assume repo files can act, keep credentials off the machines that open unknown code, and make your AI assistant ask before it runs.
Merits
- Fast, automated containment. GitHub disabling 73 repositories in 105 seconds shows platform-level defenses can move faster than any human incident response.
- A clear, teachable pattern. The attack cleanly exposes the risk of auto-executing AI-IDE config — a fixable, well-understood weakness.
- Public analysis. The incident was dissected openly by multiple security firms, giving defenders concrete indicators to hunt for.
Demerits
- The trust model itself was the target. Signed-and-authenticated no longer means safe when the key and maintainer are compromised.
- It self-propagates. A worm that spreads via stolen credentials can outrun manual cleanup and reach far beyond the initial repos.
- It hides in convenience. The exact features that make AI coding assistants useful — auto-reading and running project setup — are what got weaponized.
Caution
Do not assume "I only cloned it" means you are safe — with agentic AI tools, opening a repository can be enough to trigger execution. Equally, do not treat a repository as clean just because it belongs to a trusted organization; Microsoft's own repos were the vector here. If you opened any affected project in an AI IDE on a machine with real credentials, rotate those credentials now rather than waiting for confirmation of compromise — a self-propagating worm does not wait.
Frequently asked questions
Do I have to run a build for this to affect me? No — that is what makes it notable. The payload was triggered by AI coding tools automatically reading and acting on repository config files when the repo was opened.
Which tools were the trigger path? Claude Code, Cursor, Gemini CLI, and VS Code (with agentic behavior) were named — any assistant that auto-executes repo-level setup is in scope.
Is durabletask safe to use now? Use only pinned, verified versions and check the current advisories. The package was re-compromised on PyPI during the campaign, so avoid unpinned/latest installs until you have confirmed a clean release.
What is "Shai-Hulud" and why is it mentioned? Miasma is assessed to be a variant of the "Mini Shai-Hulud" worm publicly released in mid-May 2026. Shai-Hulud-style attacks compromise a legitimate maintainer's key and publish malicious updates that registries cannot distinguish from normal ones.
Tags
security, supplychain, ai, worm, github
Get new posts by email. No spam — unsubscribe anytime.


Responses
Sign in to leave a response.