Miasma Worm Hits Microsoft Packages Twice in Weeks — and Your SLSA Provenance Won't Save You

Supply-chain security tooling is built on a core assumption: if you can verify who signed a package, you can trust what's inside it. The Miasma worm — attributed to a threat actor tracked as TeamPCP — just demonstrated, twice, why that assumption is dangerously incomplete.

In late May, security firm StepSecurity documented the compromise of Microsoft's durabletask Python SDK on PyPI, a package for building fault-tolerant distributed workflows that pulls around 400,000 downloads per month. Then, within weeks, 73 more packages from the same Microsoft GitHub account were flagged malicious before automated systems on GitHub blocked them. The same account. The same attacker. The same malware family.

How Miasma Defeats the Trust Model

Miasma is a direct descendant of TeamPCP's Mini Shai-Hulud toolkit, which the group open-sourced. What makes it dangerous isn't any novel software vulnerability — it doesn't exploit a flaw in GitHub, npm, or the package registry infrastructure. Instead, it exploits the trust model underpinning the modern engineering ecosystem.

Here's the attack chain:

1. Credential theft first. Attackers compromise a legitimate maintainer's credentials — in this case, a Microsoft developer account — giving them authenticated publishing rights.
2. OIDC token harvest. The malware specifically targets OIDC (OpenID Connect) tokens used in SLSA (Supply-chain Levels for Software Artifacts) provenance attestation. SLSA is designed to give consumers cryptographically signed guarantees about a package's build integrity.
3. Publish with valid provenance. Because the attacker holds a legitimate GitHub OIDC token, the malicious build gets published with valid SLSA provenance. Conventional scanners see a routine, trusted update — because, from a signature-verification standpoint, it is one.
4. Per-infection encrypted payloads. Miasma generates a uniquely encrypted payload for each individual infection. Hash-based IOCs are functionally useless here; the file signature changes with every package version.

As Cloudsmith put it: the worm "does not exploit any software vulnerability in GitHub or npm. Instead, it exploits the underlying trust model of the modern engineering ecosystem."

This is a meaningful distinction. SLSA provenance tells you who signed the build and where it came from. It cannot tell you whether the human behind those credentials was compromised.

The AI Agent Trigger

The second wave of 73 compromised packages introduced a particularly sharp detail: the credential-stealing payload fires as soon as a developer opens a package in an AI coding agent. Confirmed affected agents include Claude Code, Gemini CLI, Cursor, and VS Code.

This is a significant escalation in trigger design. A developer doesn't need to install and execute the package in a traditional sense — the act of browsing or loading it inside an agentic environment is enough. Given how many developers now use AI agents to explore unfamiliar codebases, read source, and prototype integrations, this surface area is enormous.

Once triggered, the 28 KB payload goes wide:

• Credential stores for AWS, Azure, and GCP
• Kubernetes configurations
• Password managers
• Configurations from over 90 developer tools

It then attempts lateral movement through cloud infrastructure to infect other developer machines. Notably, more recent Miasma variants have added targeted collectors specifically engineered for cloud identities in GCP and Azure, moving beyond local secret scraping toward direct access to live cloud environments.

The Double-Compromise Problem

Perhaps the most operationally alarming aspect of this incident: the same Microsoft GitHub account was compromised in both the May attack and the late-June wave. Why?

Two plausible explanations exist, and neither is reassuring:

• Incomplete credential rotation. Microsoft may not have fully cycled credentials for the account after the first breach.
• Re-infection via a second package. If a Microsoft developer ran any of the compromised packages on their machine after the May incident — before the account was cleaned — Miasma could have re-harvested fresh credentials and handed them back to TeamPCP.

Microsoft has not publicly clarified which scenario applies. What this shows is that remediation after a Miasma-class infection is non-trivial. Because payloads are uniquely encrypted per infection and hash-based detection fails, you cannot simply scan for known-bad files. You need to assume every credential that was accessible from a compromised machine is burned.

Where SLSA Boundaries Actually Fall

Red Hat's Andrew McNamara addressed this directly after a parallel Miasma campaign poisoned dozens of Red Hat packages. SLSA provenance attestation was never designed to assert that a maintainer's credentials are uncompromised — it attests build-time integrity for a specific artifact given authenticated inputs. The threat model it protects against is build-system tampering and artifact substitution after publishing, not stolen publishing credentials.

This doesn't make SLSA useless — it eliminates a real class of attack. But it means SLSA needs to be layered with:

• Multi-party release signing (requiring more than one maintainer's sign-off for a publish action)
• Anomaly detection on publish patterns (new versions from accounts that haven't published in months, unusual payload size changes, unexpected dependency additions)
• Short-lived, scoped publishing tokens that reduce the window of exposure if credentials are stolen
• Behavioral monitoring in CI/CD runners, since Miasma specifically targets the cloud identities available to those runners

What You Should Do Right Now

If your team has interacted with any of the 73 flagged packages — especially inside an AI coding agent:

• Treat all credentials on the affected machine as compromised. Rotate AWS/Azure/GCP keys, Kubernetes configs, and any secrets accessible from that environment.
• Audit CI/CD runner credentials. OIDC tokens and service account keys reachable from a runner are prime targets.
• Check for lateral movement. Miasma is designed to spread; inspect other developer machines and infrastructure that share credential stores or network access.
• Don't rely on hash-matching to determine whether you were hit. Per-infection payload encryption means your scanner may find nothing even on an infected machine.

The packages list is available via the Ars Technica report. GitHub's initial response — flagging removals as a generic "terms of service violation" and directing the (compromised) account owner to contact support — delayed awareness for affected developers. Microsoft acknowledged potential malicious content only days later. That gap matters: every hour between compromise and awareness is an hour during which stolen credentials can be used.

The Miasma campaign is a clear signal that supply-chain security has moved past the era where signing and provenance alone constitute a sufficient defense. Attackers are operating inside the trust boundary, not against it.