The Largest npm Worm of 2026 Carries Valid Supply Chain Attestations. That's the Real Problem.

The supply chain verification system you trust just got bypassed by a worm that carries valid provenance attestations.

On May 11, an attacker group called TeamPCP launched Mini Shai-Hulud, compromising 172 npm and PyPI packages across 403 malicious versions totaling 518 million cumulative downloads. TanStack was among the victims. The 2.3MB obfuscated payload harvested AWS, GCP, Kubernetes, and GitHub credentials from every developer who installed the compromised versions.

The attack chained three GitHub Actions vulnerabilities that, individually, seem manageable. Together, they're devastating. First, pull_request_target misconfiguration let attacker code execute in the context of the target repo. Second, cross-fork cache poisoning let malicious payloads persist in the GitHub Actions cache across the fork-to-base boundary. Third, OIDC token extraction from runner memory gave the attacker credentials needed to publish packages with valid SLSA Build Level 3 attestations.

That last part is what should keep you up at night. SLSA Build Level 3 is supposed to be the gold standard for supply chain integrity. It means the package was built by an authorized CI system with auditable provenance. These compromised packages passed that check because the attacker was running inside the legitimate CI system. The attestations weren't forged. They were genuinely produced by compromised infrastructure.

OpenAI disclosed that two employee devices lacked updated configurations to prevent malware download from the affected packages. They're revoking signing certificates by June 12, after which older macOS OpenAI apps will be blocked.

We solved this problem in package management years ago with lockfiles, signatures, and scanning. But the worm just proved that provenance attestations can be weaponized if the build system itself is the attack vector. npm's OIDC trusted-publisher has no per-publish review gate. Any workflow code path can mint tokens.

Three immediate actions: pin all GitHub Action refs to full commit SHAs (not tags), never run pull_request_target workflows that check out PR code, and treat the GitHub Actions cache as untrusted input. If your CI/CD uses any of the three patterns the worm exploited, you're vulnerable right now.