One stolen GitHub token from a 2024 infostealer breach is still active enough to infect 73 Microsoft repositories in 2026.
The worm is called Miasma. It spreads on its own, no user interaction required, once it gets a single valid GitHub Personal Access Token. It targets 13 AI coding tools, hides inside .github/setup.js, and plants a 4.3 MB AES-encrypted credential harvester that fires the moment a developer opens the project. It forged commits to look like they came from the github-actions bot. They were unsigned, unverified, and traced back to a plain git push wearing a costume.
This is not theoretical. The Red Hat @redhat-cloud-services npm scope was compromised. Thirty-two packages, 90-plus versions. A second wave hit 57 more packages with 647,204 monthly downloads at risk. The worm harvested credentials from GitHub, npm, AWS, Azure, GCP, HashiCorp Vault, Kubernetes, SSH keys, browser and wallet data, and CI/CD environments. In some scenarios, it destroyed the maintainer's home directory.
The consensus frames this as an AI tooling supply chain attack. It's not. Miasma is a credential weapon that happens to use AI tools as execution triggers. The AI angle is a distraction. The real story is that infostealer logs from 2024 are still viable attack vectors in 2026, and no one has fixed that.
The hook that won't let go
Miasma injects persistent execution hooks into .github/setup.js, a file that 13 AI coding tools automatically execute when a developer opens a project or starts a session. Claude Code fires it. GitHub Copilot fires it. Cursor fires it. Gemini CLI fires it. Run npm test and it fires.
The 4.3 MB obfuscated payload unpacks, harvests every credential it can find, then propagates. It spreads across npm, PyPI, RubyGems, GitHub repos and Actions, SSH hosts, AWS EC2 via SSM, and JFrog Artifactory. The primary C2 transport, DomainSender, POSTs exfiltrated data to api.anthropic.com/v1/api. That transport is commented out in the open-source release published by TeamPCP (tracked as UNC6780) in June 2026. Private operator builds are expected to have it re-enabled, according to OSSPReY's analysis.
One log, 32 packages, and a bot that never was
The attack vector that broke Red Hat was not a zero-day. It was a compromised employee GitHub account whose credentials appeared in commercial infostealer logs as early as April 13, 2026, the Cloud Security Alliance confirmed. Red Hat discovered the compromise on June 1. By then, the worm had already modified 32 packages under the @redhat-cloud-services scope.
The payload was a new variant of the Mini Shai-Hulud family, attributed to TeamPCP. It downloaded the Bun JavaScript runtime and launched a secondary payload that harvested credentials from every service a developer touches, Microsoft Threat Intelligence detailed. The signature string: "Miasma – The Spreading Blight."
Then the worm jumped again. On June 3, developer Ionut-Cristian Florescu's GitHub account was compromised. On June 4, the second wave hit npm. On June 6, Florescu went public with his account of the incident. By June 8, he had resolution. In the window between, the worm used his credentials to push five forged commits in 49 seconds.
73 Microsoft repos and the unsigned commit problem
The worm hit 73 Microsoft repositories. GitHub disabled those. Florescu's own repositories stayed live, he documented on Codeberg. The asymmetry is instructive. Microsoft's repos got immediate takedown. An individual developer's repos, carrying the same infection, stayed up.
The commit forgery is the mechanism that makes this work at scale. A spoofed github-actions bot commit looks legitimate to a casual reviewer. It is unsigned and unverified, proof of a plain git push with a falsified author field. Traditional SAST, DAST, and SCA tools do not catch this. The attack surface is not code. It is credentials.
Miasma does not exploit a vulnerability in any product. It does not get a CVE number. That observation, from Phoenix Security's analysis, is the core of the problem. The security industry's entire taxonomy of vulnerability management, scoring, and patching is irrelevant here. A valid token is a valid token.
The identity-authority crisis
Every organization using AI-assisted development now faces a budget reallocation question that did not exist 12 months ago. The spend that went to detection tools must shift to token governance and credential rotation. The reasoning is straightforward.
Detection cannot solve this. A worm that uses valid tokens and spoofed bot commits looks identical to legitimate automation. The only prevention is making stolen tokens worthless. That requires binding tokens to hardware.
Here is the chain no vendor will state publicly yet, but every CISO who reads the Miasma postmortem will demand: stolen PATs are a permanent, unrevocable liability unless bound to hardware. A token floating in an infostealer log from 2024 is still a key to the kingdom in 2026 because nothing ties it to a specific machine. The fix is technically feasible today—TPMs and secure enclaves are standard on enterprise laptops, and the WebAuthn standard already proves hardware-backed authentication works at scale. What's missing is the integration layer between device attestation and Git operations.
Within 18 months, at least two major cloud providers and one AI coding-tool vendor will introduce mandatory, hardware-backed token binding that ties GitHub PATs to specific developer devices. A stolen token used outside authorized hardware will simply not work. The vendor that ships this first will capture a disproportionate share of enterprise AI development tooling spend by 2028, because the alternative—continuing to trust bare tokens—will be unpurchasable from a compliance standpoint. The economics are too favorable: the first mover sets the standard, and everyone else plays catch-up while their customers demand the feature.
What would falsify this prediction? If GitHub itself ships token binding as a platform feature before any third-party vendor does, the market-share capture shifts to GitHub and away from the tooling vendors. If a major breach occurs and no vendor responds within two quarters, the timeline extends. But the pressure is already building.
The consequences cascade from there. Token rotation becomes automated and frequent, not a quarterly audit checkbox. CI/CD pipelines require hardware attestation before they can push code. Infostealer logs lose their resale value because the tokens inside them are cryptographically useless outside the original device. The underground market for credential logs contracts sharply.
The harder shift is architectural. Zero-trust for developer workflows must move from "trust but verify" to "trust is hardware-enforced." A developer's laptop becomes the root of trust. The TPM or secure enclave on that machine is the only thing that can sign a token request. No hardware attestation, no access. This re-architects how code gets shipped—and it will happen not because it's elegant, but because Miasma proved the alternative is indefensible.
What you do by Monday
Audit every active GitHub PAT. Revoke any not tied to a specific device or carrying broad scopes. Implement short-lived tokens with an eight-hour maximum. Enable GitHub's mandatory OAuth app restrictions. Monitor repositories for the string "Miasma – The Spreading Blight," the malware's signature identified by OX Security. Block npm and pip installs from unverified scopes.
Evaluate TPM and secure enclave support on developer machines now. Hardware-backed token binding is coming. The organizations that prepare their device fleet for attestation before the mandates arrive will have a quieter transition. The ones that wait will be the ones cleaning up the next Miasma.
That single 2024 infostealer token is still out there. The worm is still spreading. The solution is not better detection. The solution is making tokens worthless outside authorized hardware. The first mandatory hardware-backed token binding ships within 18 months. The clock started the moment that token was stolen—and it hasn't stopped since.
