A poisoned dependency used to mean trouble when you installed it, imported it, or shipped it. The Miasma worm moved the tripwire earlier: the risky moment can now be opening a repository in your editor.
Miasma worm is a credential-stealing supply chain campaign that researchers say disabled 73 Microsoft GitHub repositories on June 5, 2026, including core Azure Functions and Durable Task projects. StepSecurity says the malicious commit landed in Azure/durabletask through a previously compromised contributor account, then GitHub disabled 73 repositories across four Microsoft organizations within two short waves on June 5: 39 repos in 38 seconds and 34 repos in 11 seconds through its incident timeline.
The scary part is not that Microsoft got hit. Big publishers get hit. The scary part is the shape of the exploit. In the June wave, the payload was designed to run when a developer cloned a repo and opened it in tools such as Claude Code, Gemini CLI, Cursor, or VS Code, according to StepSecurity. That changes the threat model for AI coding agents from “watch what they write” to “watch what they automatically trust.” If you have been treating agent workspaces as disposable scratchpads with access to your real GitHub, npm, Azure, AWS, GCP, Kubernetes, and password manager context, this is the invoice.
What actually happened to the Microsoft repos?
On June 5, the Miasma worm campaign hit Microsoft’s Azure GitHub estate. StepSecurity lists 73 disabled repositories across four organizations: 49 in Azure, 13 in Azure-Samples, 10 in microsoft, and 1 in MicrosoftDocs. The list includes Azure/functions-action, azure-functions-host, azure-functions-core-tools, azure-functions-mcp-extension, azure-functions-agents-runtime, durabletask, and Durable Task SDK repositories for .NET, Go, Java, JavaScript, MSSQL, and other runtimes.
The chart below shows the distribution. This is not a random long tail of forgotten demos. The biggest bucket is Azure itself, with 49 of the 73 disabled repos.
The immediate operational blast was boring in the way outages are boring: pipelines broke. StepSecurity reported that workflows referencing Azure/functions-action@v1 stopped resolving when the repository went offline, and a Microsoft Learn thread gathered 20 plus developers reporting broken CI/CD. That matters because a mutable tag such as @v1 depends on the upstream repository still existing and still pointing to what you think it points to.
The technical shift matters more. In May, Microsoft’s Durable Task Python SDK on PyPI was compromised through malicious durabletask versions 1.4.1, 1.4.2, and 1.4.3. Endor Labs said those versions ran malicious code on import and that the package had roughly 417,000 monthly downloads at the time of detection through its analysis of the trojanized SDK. StepSecurity’s incident writeup says the May attack used three malicious PyPI releases inside a 35 minute window, while the June attack used repository injection and a 4.6 MB JavaScript payload instead of the earlier 28 KB Python payload.
That is a practical evolution. Package import attacks wait for runtime. Repo-open attacks go after the developer environment, where the keys live.
Why did provenance and signatures not save this?
Because provenance can tell you that a build followed an expected path. It cannot magically tell you that the path was morally pure.
Microsoft’s own security team described the earlier Red Hat Miasma wave as a supply chain attack affecting 32 maliciously modified packages across more than 90 versions under the @redhat-cloud-services npm scope, published through the legitimate GitHub Actions OIDC workflow with authentic provenance signatures through its June 2 threat analysis. The same post says the malware harvested credentials from GitHub, npm, AWS, Azure, GCP, HashiCorp Vault, Kubernetes, and developer systems, then attempted self-propagation through poisoned packages and forged SLSA provenance.
That phrase, “authentic provenance signatures,” should make every platform team uncomfortable. SLSA’s own spec defines provenance as verifiable information about where, when, and how artifacts were produced, so consumers can verify an artifact was built according to expectations through the SLSA build provenance documentation. If the attacker has the right identity, the right pipeline, or enough control over the workflow, then “expected” can become a very expensive adjective.
Cloudsmith’s read is blunt: Miasma exploited the trust model of modern engineering more than a single GitHub or npm vulnerability. It says the Red Hat wave used legitimate OIDC tokens so malicious releases carried valid SLSA provenance, and the later Microsoft spread reached 73 Microsoft GitHub repos after the campaign shifted toward source repositories and AI coding tools through its Miasma campaign analysis.
The old checklist still helps. It just no longer closes the case.
A signed artifact is still better than an unsigned artifact. OIDC is still better than long-lived publish tokens. SLSA is still better than shrugging and trusting a tarball from the sky. But none of those controls answer the question Miasma asks: should this newly cloned folder be allowed to execute anything inside an agent or editor that can see real secrets?
Why should builders care if they never touched these repos?
Because the attack targets a pattern, not a vendor.
The pattern is simple: developers increasingly give AI coding agents access to rich local context. That context includes source trees, shell history, dependency manifests, environment files, Git remotes, test commands, cloud CLIs, MCP servers, and sometimes the keys to production because “it is just my laptop.” Miasma turns that convenience layer into a credential buffet.
If you build with agents, this has four concrete consequences:
- Your editor is now part of the supply chain. VS Code settings, Cursor rules, Claude hooks, Gemini configs, and task files deserve the same suspicion you already apply to package install scripts.
- Your agent sandbox cannot share your crown jewels. A coding agent that can read your full home directory, cloud profiles, kubeconfig, npm token, GitHub token, and password manager exports is one malicious repo-open away from being a breach assistant.
- Your provenance checks need a policy layer. Trust signals should feed admission control, not replace it. A fresh package or repo from a trusted publisher still needs cooling, scanning, and behavioral isolation.
- Your incident response clock starts at clone time. If the trigger is opening the folder, waiting for an install, test run, or deployment log misses the first event.
This is why the Miasma story connects directly to agent security rather than generic dependency hygiene. We have covered the same direction of travel in Meta’s support desk agent failure: the damaging boundary is often where an agent gets authority, not where a model gets clever. In this case, the authority is local execution plus ambient credentials.
For a startup, the business risk is ugly. One compromised maintainer laptop can poison a package, leak cloud credentials, break customer deployments, and force an all-hands rotation sprint. For an enterprise, the risk is worse because internal platform teams have spent years making developer environments powerful, consistent, and connected. That power is exactly what a worm wants.
The underrated cost is roadmap drag. After one serious agent-workspace compromise, every team suddenly needs secret inventory, CI egress control, workstation hardening, artifact quarantine, and cloud token scope review. Those are worth doing. They also steal cycles from shipping.
What should you change this week?
Start with the boring controls because boring controls are the ones you can finish before Friday.
First, treat any repository-open automation as executable code. Audit for .vscode/tasks.json, .claude settings, .gemini files, Cursor configuration, setup scripts, and repo-local hooks before an agent opens the folder. StepSecurity’s guidance for affected Microsoft repos explicitly calls out suspicious .claude, .gemini, .cursor, .vscode/tasks.json, and .github/setup.js files as things to audit after exposure through its remediation section.
Second, remove ambient secrets from agent workspaces. Use separate OS users, ephemeral dev containers, short-lived cloud credentials, read-only GitHub tokens, and network egress rules. The goal is not perfect sandboxing. The goal is to make “opened the wrong repo” produce telemetry and annoyance, not a full credential rotation.
Third, pin GitHub Actions to full commit SHAs where you can. GitHub’s own security hardening guide recommends pinning actions to a full-length commit SHA and says organizations can enforce that policy through GitHub Actions security documentation. Pinning would not have made a malicious repo safe, but it would have reduced mutable tag ambiguity when Azure/functions-action disappeared.
Fourth, add an artifact quarantine step for newly published dependencies and newly cloned third-party repos. A 24 hour or 72 hour cooldown will annoy someone. Good. Miasma-style campaigns feed on automatic trust and immediate consumption.
Fifth, rehearse the credential burn-down. If a developer says, “I opened one of the affected repos in Cursor on June 5,” your team should already know which tokens to revoke first. GitHub PATs, SSH keys, npm and PyPI tokens, Azure service principals, GCP service accounts, AWS keys, kubeconfigs, Docker configs, CI secrets, and password manager exports all belong on that list.
What is the next attack likely to copy?
Expect copycats to target the invisible glue around agents.
The obvious targets are repo-local configuration files that look harmless during review and feel native to the tool. The better targets are workflow paths that fire before a human presses run: preinstall hooks, folder-open tasks, model context setup scripts, MCP server configs, extension recommendations, and agent “memory” files. If the file is designed to make a tool helpful without asking a second question, an attacker will try to make it helpful to them.
Also expect more attacks that look valid to scanners. Microsoft reported Miasma credential access across GitHub, npm, AWS, Azure, GCP, Vault, Kubernetes, CI, browser data, and wallet files. That is not smash-and-grab malware aimed at one password. It is infrastructure for moving from developer workstation to package registry to cloud estate.
The bet to make: agent security will become a platform engineering problem in 2026, not a prompt engineering problem. The teams that win will make safe paths easy: isolated agent users, default-deny egress, scoped credentials, internal mirrors, artifact policies, and clear “open untrusted repo” workflows. The teams that lose will ask every developer to remember 19 rules while their agent happily follows a poisoned setup file.
The trust boundary just moved
Miasma is a useful slap because it attacks the place teams were proud of making frictionless. Opening a repo in an AI coding agent should feel cheap. After June 5, 2026, it should also feel like crossing a security boundary.
That is the new rule: if an agent can act like a developer, it can also be compromised like one.
Sources
- StepSecurity, Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents
- Cloudsmith, The Miasma worm's path of destruction
- Microsoft Security Blog, Preinstall to persistence: Inside the Red Hat npm Miasma credential-stealing campaign
- Endor Labs, Trojanized Microsoft SDK: durabletask 1.4.1 through 1.4.3 Deliver Credential-Stealing Malware
- SLSA, Build: Provenance
- GitHub Docs, Security hardening for GitHub Actions
