We believed that signing packages solved supply chain security. We signed them using OpenID Connect (OIDC). We embedded SLSA provenance. Big registries told us: if the identity checks out, the code is safe to run.
That was a lie.
We built our security models on identity rather than behavior. We focused entirely on who signed the code, rather than what the code actually does. Late last week, this trust model collapsed when 73 Microsoft-verified open-source packages were pulled from GitHub after researchers discovered they were laced with credential-stealer malware. The packages were cryptographically signed. They had valid metadata. But they were designed to rob you blind.
What makes this incident incredibly devious is the trigger mechanism. You didn't need to compile, build, or deploy this code to set it off. It executed the moment developers opened these packages using AI coding agents.
If this happened to your machine, you must assume your environment is fully compromised. Stop. Don't run another command. Treat every AWS key, GCP configuration, and Azure token on that workstation as stolen. The attackers didn't use an exploit in the traditional sense; they simply walked through the front door using stolen publishing credentials.
GitHub’s response made things worse. Instead of clearly labeling these packages as malicious, they put up a generic notice saying they disabled them for "violating GitHub's terms of service." That is a massive failure in incident communication. It hides the immediate danger from developers who might otherwise keep their machines connected to production networks. If you designed a security perimeter protecting $2B in transaction volume, like I have, you soon realize that keeping developers in the dark is how minor breaches turn into catastrophic events. We need to apply strict zero-trust perimeters not just to our production APIs, but to the machines our engineers use to write the code itself.
The Mechanics of Miasma: How the Worm Bypassed Our Scanners
The malware in question is tracked as Miasma. It is a clone of TeamPCP’s Mini Shai-Hulud toolkit, which the threat actor recently open-sourced. If that group sounds familiar, it should. We recently dissected their work in our breakdown of the Hades Campaign against PyPI, which showed how they could hide malicious behaviors inside Python wheel setups. But while the Hades campaign relied on wheel startup hooks, Miasma takes a different path by exploiting the trust relationships of the repositories themselves.
This worm didn't exploit zero-day bugs in npm or GitHub. It took advantage of human admin failures.
The attacker compromised Microsoft maintainer credentials and immediately used them to request legitimate GitHub OIDC tokens. These tokens are designed to link actions back to verified developers under the Supply-chain Levels for Software Artifacts (SLSA) framework. Because the OIDC token was valid, the attacker published a malicious build containing a 28 KB payload, and it carried perfect, cryptographically signed SLSA provenance.
To any automated scanner in your CI/CD pipeline, the update looked like a routine, approved release. It came from a trusted account. It was signed by the official publisher.
Security firm Cloudsmith pointed this out in their analysis: "The genius of this Miasma worm lies in how it adhered to legitimate workflows." What makes this worse is the polymorphism. Miasma creates a uniquely encrypted payload for each individual infection. That means the file hash is constantly changing. Traditional scanners that look for known bad signatures are useless. If you are relying on simple hash lookups to protect your environment, you are fighting yesterday's war. Andrew McNamara of Red Hat also highlighted this in a blog post detailing where SLSA's boundaries fail to protect us. The signing process proves where the code came from. It does not prove that the code is safe.
The AI Catalyst: Why Coding Assistants are a Double-Edged Sword
Typically, malware needs you to do something explicit. You have to double-click an installer or run a specific terminal command. Not this time.
The Miasma worm targets the way developers use modern generative AI. It is triggered as soon as a developer opens the compromised package in an AI agent, such as Claude Code, Gemini CLI, Cursor, or VS Code.
Here is why this works: to provide helpful explanations, write tests, or refactor your files, these AI models must ingest workspace files. They scan the directories, read files, and often run baseline commands or setup hooks within your IDE to build their context. The moment the agent indexes the malicious files, the payload executes. It essentially turns the AI assistant into an automated execution agent for the attacker.
We are moving fast to integrate AI into our workflow. We give these agents broad access to our shells, file systems, and environment variables because it makes writing code feel magical. But when we do that without putting up walls, we are begging for trouble.
This is exactly why we need to move toward restrictive runtime perimeters for AI. As we discussed in our look at Claw Patrol's security guardrails, the Deno team had to build a custom interceptor just to stop autonomous tools from running wild on production databases and repositories. Without those kinds of protocol-level controls, your AI assistant is just a high-speed vector for remote execution. If you open a poisoned file, the AI agent is going to read it, trigger the hook, and hand your credentials over before you even finish typing your prompt.
Beyond the Workstation: Scavenging Cloud Credentials
If the malware only targeted local files, it would be bad. But Miasma is far more ambitious.
The payload is only 28 KB. Small. Yet it is packed with specific scrapers targeting AWS, GCP, Azure, Kubernetes, password managers, and over 90 different developer tool configurations. The developers behind Miasma know exactly where we hide our secrets. They know that a single developer workstation is often the keys to the entire corporate kingdom.
Once Miasma executes, it doesn't just upload a text file of passwords. It is designed to grab OIDC tokens, cloud credentials, and API keys. It then attempts to move laterally.
If your workstation is connected to a CI/CD runner or shares a network segment with automated build systems, Miasma tries to infect those systems too. Its goal is persistent, live access to production cloud environments. When I design perimeters for high-volume transactions, my biggest headache is never the external API firewall. It is the developer who has a hard-coded AWS admin session lying in their shell history.
TeamPCP built this malware to exploit that exact point of failure. By moving away from simple local file extraction and focusing on GCP and Azure identity stores, they can pivot from a single infected machine to an entire cluster of cloud services. In a matter of minutes, a developer looking at a helper package in VS Code can hand an adversary full access to a corporate cloud tenant.
The Double Compromise: Microsoft’s Systemic Credential Failure
What makes this situation truly infuriating is the element of déjà vu. This is the second time in less than two months that the exact same Microsoft repository account has been compromised to distribute malware.
This trend of exploiting infrastructure is a recurring theme, often seen in incidents like the DragonForce exploitation of Microsoft Teams relays.
Back in mid-May, StepSecurity documented a compromise of Microsoft's durabletask Python SDK on PyPI. That package receives over 400,000 downloads a month. The attackers poisoned the package by compromising developer credentials, allowing them to bypass the build pipeline entirely. Now, a few weeks later, we are dealing with the exact same compromised entry point. Similarly, supply chain security remains a challenge for major ERP systems, as seen in the Oracle PeopleSoft zero-day breach by ShinyHunters.
How does a multi-trillion-dollar company let the same publishing account get hijacked twice in a row?
Maybe they didn’t rotate all the credentials. Maybe the attackers had a persistent backdoor they didn't clean up, or a Microsoft developer machine remained infected, silent, and stealing newly rotated keys. Microsoft's response has been slow and quiet. They sent a brief email saying they were "investigating potential malicious content." That’s not a security advisory; it's corporate damage control.
If you are running these packages, you cannot wait for Microsoft to release a patch or a post-mortem. You have to assume your systems are compromised.
Here is what you need to do: first, drop everything and isolate the affected machines. Wipe them. Don't just run an antivirus scan—re-image the OS completely. Second, rotate every single API key, AWS role, GCP credentials, and Kubernetes secret that was present on those machines. Third, review your cloud logs. Look for unusual API activity starting from the date you opened those packages.
This is a wake-up call for the entire software supply chain. Cryptographic signatures are great, but they only tell you who published the code, not whether their machine was clean when they did it. If we don't start treating developer environments with the same Zero-Trust standards we apply to production databases, we are going to keep having this conversation month after month.