The Provenance Paradox: Why SLSA Signing Couldn't Stop the TanStack Worm

TL;DR

The Mini Shai-Hulud npm supply chain worm is the first to ship with valid SLSA Build Level 3 provenance attestations. The worm didn't steal credentials — it hijacked the legitimate build pipeline and minted authentic signatures for malicious code. SLSA verified the build process was clean; it had no way to verify the code was safe.

The Paradox: Authenticated Evil

On May 11, 2026, attackers published 84 malicious npm package versions across 42 @tanstack/* packages with a critical property: valid Sigstore-issued SLSA provenance certificates. These cryptographic attestations prove the packages were built from the TanStack/router GitHub repository using the official release workflow.

They were.

The malware didn't forge the attestations or steal npm tokens. It extracted the GitHub Actions runner's OIDC token from process memory (/proc/<pid>/mem) while the workflow was executing, then used that token to publish malicious code directly to npm. From npm's perspective, the signature is legitimate; Sigstore verified the build process correctly; the chain-of-custody is unbroken.

What SLSA cannot verify: whether the code in that build process was safe.

How the Weapon Was Forged

Three vulnerabilities chained:

1. Pwn Request (pull_request_target): Fork PR triggers base-repo workflow, executes fork-controlled code.

2. Cache Poisoning: Malicious binary injected into shared GitHub Actions cache, restored on next main-branch push.

3. OIDC Token Extraction: Attacker code runs during workflow, dumps runner memory, extracts id-token before cleanup.

The technical sophistication is worth noting: the memory extraction script reused code from the tj-actions/changed-files compromise (March 2025), showing TeamPCP recycles proven tradecraft. The obfuscation layer uses Fisher-Yates substitution (ctf-scramble-v2, verbatim across SAP, Bitwarden, and TanStack waves), suggesting a shared malware factory.

But the deeper insight is the provenance betrayal. In 2024–2025, the industry moved aggressively toward SLSA: GitHub made OIDC trusted publishing standard, npm integrated Sigstore verification, and security teams began relying on provenance attestations as a control. The message was clear: "Build attestation is your supply chain firewall."

This attack proved the firewall has a fundamental blind spot.

Why Provenance Alone Can't Scale

SLSA and Sigstore are cryptographically sound. The problem is not the math; it's the scope.

SLSA verifies the build pipeline, not the build artifact. It answers: "Did this code run through the official CI/CD?" It does not answer: "Is this code malicious?"

Distinguishing safe from unsafe code at scale requires:

• Semantic analysis (hard: needs LLMs or static analysis)
• Behavioral sandboxing (hard: requires runtime inspection)
• Threat intelligence correlation (hard: needs real-time feeds)

Provenance does none of these. It is a chain-of-custody mechanism, not a threat detection mechanism.

When the attacker controls the pipeline, SLSA becomes a liability. It provides confidence where none is warranted. Defenders see a valid signature and relax; attackers see a signature stamped on malware and know the alert threshold has risen.

The Escalation Cycle

The TanStack worm self-propagated to over 170 additional packages (@mistralai, @uipath, @opensearch-project, @squawk/*). Each inherited the same SLSA provenance properties because the attacker reimplemented the attestation generation:

// From the deobfuscated payload:
// generateKeyPairSync + sign to forge Sigstore-compatible in-toto provenance
// Every republished package carries what appears to be valid SLSA attestation

The payload exfiltrates credentials, republishes packages via stolen GitHub tokens, and each new publish carries valid provenance. From the attestation layer's perspective, this is indistinguishable from legitimate republishing.

What Happens Now

The industry faces a choice:

Option 1 (Harder): Extend SLSA to include code safety heuristics. Provenance + static analysis + entropy checks. But this requires:

• Standardizing what "safe code" means (unsolved)
• Running analysis on every build (compute cost)
• Handling false positives in legitimate code (noisy, impractical)

Option 2 (Current): Keep provenance as a chain-of-custody tool, but layer behavioral defenses:

• Artifact sandboxing: run npm install in isolated containers
• Hook-blocking: disable lifecycle scripts by default (npm install --ignore-scripts)
• Supply chain guardrails: deploy SBOM scans + runtime integrity checks

Option 3 (Lyrie's angle): Assume the pipeline is compromised. Deploy autonomous agents to monitor for behavioral anomalies during install time — network exfil, credential access, privilege escalation — and block malicious hooks before they execute.

The Defender's Asymmetry

This attack illustrates a hard asymmetry:

• Attacker: Compromises one central pipeline, reaches 170+ packages instantly via self-propagation.
• Defender: Must audit 170 packages, rotate 170 sets of credentials, block 170 versions, verify cleanup across 170 repos.

The attacker's kill chain compressed into 6 minutes. The defense timeline stretched across 48 hours.

In a world of autonomous attacks (and this is increasingly that world), the patch-and-rotate model is not scaling. Defenders need to detect and block the _behavior_, not wait for the artifact signature to be analyzed by humans downstream.

Lyrie's Read

This is not a SLSA failure; it is a SLSA category error. We asked provenance to do threat detection. Provenance answers questions about origin, not safety.

The real lesson: supply chain security in 2026 requires concurrent, autonomous monitoring of build behavior and artifact behavior. When npm install executes, your defense layer must see:

• What secrets are being accessed (and block exfiltration)
• What network connections are being made (and block C2)
• What processes are being spawned (and block RCE)

This is what Lyrie's autonomous defenders do. Not by trusting attestations, but by assuming they can be forged — and watching what happens at runtime.

The TanStack worm teaches an uncomfortable lesson: authentication is not authorization. Valid SLSA provenance on malicious code is a philosophical problem the industry hasn't solved yet.

Recommended Actions

For CISOs:

1. Audit your trust in SLSA attestations — they are not malware gates.

2. Require npm install --ignore-scripts in all CI/CD and development machines.

3. Deploy artifact sandboxing: run npm install in throwaway containers, inspect for anomalous network/filesystem activity.

4. Implement SBOM scanning + behavioral guardrails at install time.

For DevOps/SRE:

1. Rotate all GitHub tokens immediately if you installed any affected package on May 11.

2. Purge GitHub Actions cache across all repositories (cache is a trust boundary).

3. Audit pull_request_target workflows — if they execute fork code, eliminate them or add hard permission controls.

4. Pin third-party action refs to SHAs, not floating tags.

For Security Teams:

1. Deploy runtime hooks to intercept and block credential exfiltration from npm install.

2. Monitor for the "dead man's switch" pattern: gh-token-monitor daemon at ~/.config/systemd/user/gh-token-monitor.service or ~/Library/LaunchAgents/com.user.gh-token-monitor.plist.

3. Check .claude/settings.json and .vscode/ for persistence payloads across developer machines.

---

Lyrie.ai Cyber Research Division