Six Minutes That Broke the Trust Chain
On May 10, 2026, attackers compromised the TanStack npm publishing infrastructure and pushed 84 malicious package versions across 42 TanStack packages in a window of approximately six minutes. TanStack is one of the most widely used open-source ecosystems in the React and JavaScript world — TanStack Query alone has over 44 million weekly npm downloads. The malicious versions contained credential-harvesting code that targeted developer environment variables, authentication tokens, and cloud credentials.
What makes this attack structurally different from every previous npm supply chain compromise: the malicious packages carried valid SLSA provenance attestations. SLSA (Supply-chain Levels for Software Artifacts) is the integrity verification framework that the open-source ecosystem adopted specifically to prevent this class of attack. The provenance attestation is meant to prove that a package was built from the claimed source code, by the claimed build system, without tampering. The TanStack attack defeated that proof.
How SLSA Provenance Was Defeated
SLSA provenance works by generating a cryptographically signed attestation during the build process. The attestation records what source code was built, what build system was used, and what the output artifact was. Consumers can verify the attestation to confirm the package matches the claimed source. The assumption is that if the build system generates a valid attestation, the package is trustworthy.
The TanStack attackers compromised the publishing credentials that interact with the build system. Because the malicious code was injected at a point in the pipeline that the SLSA attestation process treated as trusted, the provenance attestation was generated for the tampered artifact. The attestation was technically valid — it accurately recorded that the compromised build system produced the compromised package. SLSA verified the integrity of a poisoned process. This is the first documented npm attack where SLSA provenance was carried on a malicious package.
The implications are severe. Organizations that adopted SLSA verification as their supply chain security control received no protection from this attack. The provenance check passed. The package looked legitimate by every automated metric. The trust framework itself was the vulnerability.
The Blast Radius: OpenAI, Mistral AI, UiPath
TanStack packages are transitive dependencies for a significant portion of the React ecosystem. When 42 packages are simultaneously compromised, the blast radius extends to every project that depends on any of them — directly or transitively. Over 160 organizations installed the compromised versions during the attack window. Among them: OpenAI, Mistral AI, and UiPath.
OpenAI's postmortem confirmed that 2 employee development machines installed the compromised packages and executed the credential-harvesting payload. The harvested credentials were rotated immediately after detection, but the incident demonstrates that even the most security-conscious AI companies are vulnerable to supply chain attacks that pass integrity verification. If OpenAI's supply chain controls did not catch packages with valid SLSA provenance, no organization's controls caught them.
Mistral AI and UiPath were also confirmed as secondary victims. The attack's 6-minute window was short enough that many organizations' lockfiles prevented automatic installation, but long enough that CI/CD pipelines running fresh installs during that window pulled the compromised versions.
The Dependency Tree Problem
The TanStack attack is a direct consequence of the npm ecosystem's dependency architecture. A typical React application has between 800 and 1,200 transitive dependencies. A Next.js project starts with over 1,000. Each dependency is a trust relationship with a maintainer, a build system, and a publishing pipeline. The TanStack attack compromised one publishing pipeline and reached 160+ organizations through the dependency graph.
Frameworks with minimal dependency trees are structurally immune to this class of attack. Hugo has zero npm dependencies — it is a single Go binary. Astro has reduced its dependency footprint significantly compared to older Node.js frameworks. Static site generators that produce HTML at build time and ship zero JavaScript to production eliminate the entire category of runtime supply chain risk. The framework choice determines the supply chain attack surface.
Beyond SLSA: What Actually Works
SLSA provenance is not broken — it performed exactly as designed. It verified that the build system produced the artifact. The problem is that the build system was compromised. No integrity verification system can protect against a compromised trusted component. The TanStack attack demonstrates that provenance attestation is a necessary but insufficient supply chain security control.
Effective supply chain defense requires layered controls: lockfile pinning to prevent automatic upgrades during attack windows, reproducible builds that allow independent verification, runtime behavior monitoring that detects credential exfiltration regardless of provenance status, and — most fundamentally — reducing the number of dependencies to reduce the number of trust relationships. An organization with 50 dependencies has 50 potential TanStack-class exposures. An organization with 1,200 dependencies has 1,200.
What This Means for Framework Selection
The TanStack attack reframes framework selection as a supply chain security decision. Every npm dependency is a trust relationship with an external publishing pipeline. Every transitive dependency extends that trust transitively. The SLSA framework — the industry's best answer to supply chain integrity — did not prevent this attack. Organizations selecting web frameworks in 2026 need to weigh dependency count alongside performance, developer experience, and feature set. Dependency count is attack surface.
Two OpenAI employee devices were compromised because TanStack packages appeared in their dependency tree and the compromised versions passed every integrity check. The packages were not flagged by npm audit. They were not flagged by SLSA verification. They were not flagged by any automated security tool. They were detected through behavioral monitoring after the credentials had already been harvested. The cost of a large dependency tree is measured in incidents like this.
