84 npm package artifacts across 42 @tanstack repositories, all carrying cryptographically valid SLSA Build Level 3 attestations, were published by an attacker in May 2026—and the attestations were perfect. That's the problem. The "Mini Shai-Hulud" attack didn't forge signatures; it compromised the build platform that produced them.
Andrew McNamara (Red Hat) lays out exactly what happened on the OpenSSF blog. The attacker chained a GitHub Actions pull_request_target misconfiguration, cache poisoning, and OIDC token extraction. A malicious PR ran code in TanStack's base repository context, poisoned a shared pnpm cache, then the legitimate release workflow restored that poisoned cache. Inside that workflow, attacker-controlled code scraped the runner memory for the ambient OIDC token and signed directly to npm via Sigstore's Fulcio CA. The resulting npm provenance attestations accurately named builder, repository, and workflow—because the pipeline was legitimate. The code inside it was not.
SLSA Build L3 Closes the Isolation Gap That L2 Leaves Open
npm's built-in provenance hits Build Level 2: the build ran on a hosted platform and the provenance is authenticated. That stops dependency confusion dead—an attacker can't forge provenance from a repo they don't control. But L2 does not require isolation between builds. The TanStack attack violated all three L3 isolation requirements: cache poisoning across builds, signing key accessible to the build, and persistent influence across runs. A platform meeting L3 would have blocked the cache-poisoning vector entirely. The distinction is trust: at L2 you trust each individual developer; at L3 you trust the platform to be an external observer that the build process cannot reach.
The attack exploited exactly the gap between L2 and L3. Policy on expected builders wouldn't have caught it—the attestations named the correct builder, repo, and workflow. What would have flagged it? The workflow runs that published the malicious packages completed with status: failure while publishing mid-execution. Standard SLSA consumer tooling doesn't check workflow run status, but monitoring publish events from failed runs would have cut the exposure window by hours.
Policy and Operational Hygiene Fill What SLSA Alone Cannot
SLSA records evidence. It answers "what happened?" It does not answer "was that good enough?" Once attacker code runs inside the trusted workflow, SLSA's build-time guarantees are behind you. The boundary of observability is the boundary of the trust context. Policy on top of SLSA—like SLSA v1.2's Source Track for code review attestations, or Verification Summary Attestations (VSAs)—can connect evidence to decisions. Rebuilders running on isolated infrastructure and comparing reproducible builds add another layer: a poisoned build produces divergent output a clean rebuild won't match.
Workflow hygiene is separate and necessary. pull_request_target is a known vector for credential theft. Least-privilege permissions, pinned actions by digest, and treating shared caches as cross-workflow trust boundaries are operational choices that make SLSA meaningful. The TanStack postmortem already documents the remediations: removed pull_request_target, pinned all actions to commit SHAs, enforced phishing-resistant 2FA, and added automated workflow security scanning with zizmor.
Two assumptions failed here: that generating provenance is the same as meeting the isolation requirements provenance depends on, and that meeting those requirements is sufficient on its own. The controls to close most of those gaps exist today. The hard part is choosing which trust boundary you're willing to bet your supply chain on.
Source: Mini Shai-Hulud: Where SLSA's Boundaries Fall
Domain: openssf.org
Comments load interactively on the live page.