The packages passed every check. The provenance certificates were valid. The cryptographic signatures were clean. Every automated security tool that looked at the 84 malicious npm packages published on the evening of May 11, 2026, saw exactly what it was supposed to see: the verified artefacts from a trusted maintainer, built by a legitimate CI pipeline.
That was the point. Nobody stole a password. Nobody phished a developer. Nobody brute-forced an account. The attacker used TanStack’s own release infrastructure to ship the malware, and by the time the first alert was raised, the packages had already been sitting on the registry for twenty minutes.
This is not a story about a weak password or a careless developer. It’s a story about what happens when the tools built to verify trust become the delivery mechanism for an attack.
What Happened: The TanStack Compromise
Between 19:20 and 19:26 UTC on May 11, 2026, an attacker published 84 malicious versions across 42 @tanstack/* npm packages. The entire operation ran in six minutes. @tanstack/react-router alone pulls more than 12 million weekly downloads. The attacker didn’t target TanStack because it was vulnerable. They targeted it because it was trusted.
The attack chained three vulnerabilities, none of which was individually catastrophic, but together, they were enough.
Here’s the sequence:
The attack produced 84 malicious npm package versions that still carried valid SLSA Level 3 provenance badges. The packages were genuinely built and signed through TanStack’s GitHub Actions pipeline, proving an uncomfortable reality: provenance can verify where software was built, not whether the build environment itself had already been compromised.
The payload, a heavily obfuscated 2.3MB JavaScript file, executed automatically during npm install through a prepare hook. Once active, it harvested GitHub tokens, cloud credentials, SSH keys, Kubernetes accounts, CI/CD secrets, and npm authentication files. It also installed a persistent daemon, gh-token-monitor, which checked stolen GitHub tokens every 60 seconds.
The malware included a destructive failsafe: if a victim revoked their compromised GitHub token, it triggered rm -rf ~/, wiping the developer’s home directory. Researchers at StepSecurity detected and reported the malicious packages within 20–26 minutes of publication. The affected versions were deprecated within hours, and npm removed the packages before midnight UTC.
The Bigger Picture: Mini Shai-Hulud
Mini Shai-Hulud was not just a compromised npm package incident; it was a self-propagating supply chain worm that moved across trust boundaries inside modern developer infrastructure. TanStack became the initial entry point, but the campaign quickly expanded into a much larger operation targeting npm, PyPI, AI SDKs, CI/CD pipelines, GitHub tokens, and cloud credentials.
The attackers exploited trusted GitHub Actions workflows, poisoned shared caches, extracted OIDC tokens directly from runner memory, and published malicious packages through legitimate signed pipelines. Because the malware operated inside verified infrastructure, the compromised packages still carried valid SLSA provenance badges and appeared trustworthy to users and automated systems alike.
Researchers later identified hundreds of malicious package versions across multiple ecosystems, including npm and PyPI. The worm also introduced new operational techniques, including decentralized Session-network command channels and automated self-propagation into other repositories with publish access. Rather than breaking encryption or bypassing signatures directly, the campaign weaponised the implicit trust relationships between developer tools, CI systems, package registries, and cloud infrastructure.
What OpenAI Found
OpenAI’s exposure to the TanStack supply chain attack remained limited but significant enough to trigger a formal internal investigation and emergency security response. Two employee devices installed compromised @tanstack packages before updated protections had been rolled out, allowing the malware to harvest credentials and attempt exfiltration from a small subset of internal engineering repositories.
The company confirmed that some credential material, including macOS code-signing certificates, was successfully stolen. However, OpenAI stated that investigators found no evidence of compromise involving user data, production systems, intellectual property, or published software. The incident was contained within OpenAI’s corporate engineering environment.
In response, OpenAI isolated the affected devices, paused parts of its deployment infrastructure, rotated compromised certificates, and updated internal security controls. The incident also forced macOS users of several OpenAI desktop tools to update their applications before Apple’s notarization system began rejecting software signed with the old certificates.
The Deeper Issue
What the TanStack attack actually broke was not a password policy or an unpatched CVE. It broke the assumption that cryptographic verification is the same thing as security.
SLSA provenance, OIDC trusted publishing and Sigstore attestations, these are real improvements to supply chain security. They represent years of work by the open source security community. The TanStack attack used all of them correctly and still shipped malware. The packages were built by the right repository, by the right workflow, on the right branch. Every statement the provenance certificate made was technically true. The build environment just happened to be poisoned.
The structural gap the attack exposed is the split between trust boundaries. GitHub Actions workflows that handle CI and those that handle releases are supposed to live in different trust contexts. The pull_request_target trigger exists to give CI workflows access to base-repo secrets, but it requires explicit, careful management of what fork code is and isn’t allowed to execute. TanStack’s bundle-size workflow ran in a privileged context without that gate. The GitHub Actions cache — a performance optimisation, crossed the boundary between those contexts and carried the payload across.
The broader implication is harder. Any npm package using OIDC trusted publishing without branch-and-workflow pinning is vulnerable to this class of attack. Any GitHub Actions workflow that reads from a shared cache without considering what was written to that cache carries residual risk. These are not obscure configurations. They are common patterns across thousands of open source repositories.
Key Takeaways
- The attack used no stolen credentials. TanStack’s legitimate OIDC identity published the malware. This is a new and significant threat model.
- Valid SLSA provenance is not a safety guarantee. It attests to where a package was built, not whether the build environment was clean.
- The pull_request_target trigger is a known dangerous pattern. GitHub calls it the “Pwn Request.” Any workflow using it must not execute fork code in a privileged context.
- Build caches are attack surfaces. Treat the cache as untrusted input. Isolate CI and release caches across trust boundaries.
- Run npm ci –ignore-scripts in CI/CD. This blocks the prepare lifecycle hook, the primary delivery mechanism for the Mini Shai-Hulud payload.
- OpenAI’s exposure stayed internal. Two devices, some credentials, and a certificate rotation. User data and production systems were not affected.
- The worm is still active. TeamPCP compromised Microsoft’s durabletask Python SDK on May 19. This is an ongoing campaign, not a closed incident.
- If you installed affected @tanstack/* packages on May 11: treat the install host as compromised, remove the gh-token-monitor daemon before revoking tokens, and rotate all secrets.
Conclusion
Six minutes. Eighty-four packages. One hundred and seventy libraries were affected by the end of the day. And two laptops at one of the world’s most scrutinised AI companies.
The Mini Shai-Hulud campaign is not a story about someone finding a backdoor in npm. It’s a story about an attacker reading the documentation more carefully than the defenders did. The pull_request_target risk was known. The GitHub Actions cache trust boundary was documented. OIDC publishing without branch pinning was identified as a vulnerability class before this attack. TeamPCP just put those pieces together with enough precision to move through a trusted pipeline undetected.
The supply chain security tooling that exists today, SLSA, OIDC trusted publishing, Sigstore attestations, and automated scanners, is genuinely valuable. It raises the cost of a wide class of attacks. It did not raise it high enough here. What’s needed isn’t just better tools. It’s a clearer understanding that verifying identity is not the same as verifying safety. A package can be built in exactly the right place, by exactly the right pipeline, and still carry a payload if the environment that ran the build was poisoned upstream.
The question every maintainer should be sitting with right now:
How much authority am I granting a process I don’t fully control? If the answer is “enough to publish,” the worm is already halfway home.
