Home / Critical Brief / No. 014

The TanStack npm Compromise

Malicious Packages Signed Under a Legitimate OIDC Trusted Publisher, Where a Valid Provenance Signature Did Not Mean a Trustworthy Artifact

Pillar 01 · Verifiable Origin Code Provenance Identity & Auth
Incident date
2026-05-11
Published
2026-05-31
Authors
Lemma Critical Team
Related Pack
Pack AIncident Response

TL;DR

In May 2026, malicious versions of the @tanstack/* packages reached npm. The attacker stole no token; they hijacked TanStack’s legitimate OIDC trusted-publisher integration mid-workflow and shipped malicious artifacts through the legitimate channel, signed under a valid OIDC identity. A signature attests who published an artifact, not whether its contents are the intended build output, and pre-detection fetches had little reason to suspect them precisely because the signatures were valid. Detection and pre-execution attestation are complements, not substitutes.

Incident Overview

  • Affected: 42 packages under the @tanstack/* npm namespace, 84 malicious versions total (CVE-2026-45321, CVSS 9.6)
  • Publish window: 2026-05-11, 19:20–19:26 UTC (about six minutes)
  • Core method: not npm-token theft. The attacker hijacked TanStack’s legitimate GitHub Actions OIDC trusted-publisher integration during workflow execution and published the malicious versions signed under the legitimate OIDC identity. The signed provenance attestations remained valid while the malicious artifacts moved through the legitimate channel
  • Vulnerability chain: misconfigured pull_request_target (“Pwn Request”) → GitHub Actions cache poisoning across the fork↔base trust boundary → in-memory extraction of the OIDC token from the Actions runner process
  • Payload: ~2.3MB obfuscated router_init.js. Exfiltrated AWS / GCP / Kubernetes / HashiCorp Vault / npm / GitHub tokens / SSH private keys / .npmrc. Polled GitHub tokens every 60 seconds and, upon detecting revocation, ran rm -rf ~/ to wipe the home directory
  • Attribution: TeamPCP, per StepSecurity. Part of the “Mini Shai-Hulud” worm campaign that contaminated more than 170 packages across npm / PyPI on the same day (Mistral AI, UiPath, OpenSearch, Guardrails AI, and others)
  • Detection: an external researcher (ashishkurmi at StepSecurity) publicly detected the malicious publishes 20–26 minutes after they landed
  • Adjacent activity: TeamPCP also compromised Aqua Trivy (2026-03) and the Bitwarden CLI npm package (2026-04). The same actor is associated with the same-day GitHub internal-repository compromise covered in Brief 015

Timeline

  • 2026-03 / 2026-04: TeamPCP compromises Aqua Trivy and the Bitwarden CLI npm package (preceding campaigns)
  • 2026-05-11 19:20–19:26 UTC: 84 malicious versions land across 42 @tanstack/* packages, signed and published via the legitimate OIDC channel
  • 2026-05-11, 20–26 minutes later: StepSecurity researchers publicly detect and announce the publishes
  • 2026-05-11, same day: the same actor contaminates more than 170 packages across npm / PyPI (“Mini Shai-Hulud”)
  • 2026-05 onward: CVE-2026-45321 is assigned, TanStack publishes a postmortem, and IOCs / response guidance are consolidated by vendors

Note: proper nouns and CVE identifiers are based on primary sources (research labs, the GitHub Advisory Database, NVD, and the like); each implementation’s remediation status varies over time, so consult the latest information.

Attack Vector

  1. Pwn Request abuse: exploit the misconfigured pull_request_target setting so that a fork PR can land code in the base repository’s trusted context, creating a foothold inside the workflow
  2. Cache poisoning: poison the GitHub Actions cache across the fork↔base trust boundary so that attacker-controlled code runs on the runner during workflow execution
  3. OIDC token extraction: extract the OIDC token from the Actions runner process memory at runtime, transiently gaining the right to legitimately sign and publish as npm’s trusted publisher
  4. Publish via the legitimate channel: instead of using a stolen token, use the hijacked legitimate OIDC identity to publish 84 malicious versions. The provenance signatures remain valid throughout
  5. Payload execution on install: in the consuming environment, router_init.js exfiltrates AWS / GCP / Kubernetes / Vault / npm / GitHub / SSH credentials
  6. Destructive trigger: on detecting that a GitHub token has been revoked, execute rm -rf ~/ to wipe the home directory of the affected environment

Structural Argument

The incident belongs to the code-provenance category of Pillar 01 (Verifiable Origin). The central failure primitive is “provenance assurance depended on the publisher-identity signature (OIDC trusted publisher), and once that identity was hijacked at runtime, the malicious artifact moved through the legitimate channel with a valid signature still attached.” A signature attests “who published this”; it does not attest “the contents of this artifact are the intended, reviewed build output.” identity-auth (hijack of the OIDC identity) is noted as a secondary category.

The same code-provenance category as Brief 004 (Megalodon GitHub supply chain), but a different primitive. Brief 004 was a direct push using stolen developer credentials; this incident is a runtime hijack of a legitimate OIDC trusted publisher. Both share the structure that “an artifact’s origin is accepted while remaining decoupled from any layer that independently verifies it.” This incident sits alongside Brief 015 (the GitHub internal-repository compromise and the poisoned VS Code extension) as part of the same actor’s (TeamPCP) campaign against developer trust surfaces, and is adjacent to Brief 010 (the Claude Code impersonation distribution) on the shared theme of “abuse of trust signals.” It is described as “the first supply-chain worm to ship with valid signed provenance,” sharply illustrating the gap between signature validity and artifact integrity.

The detection–proof gap

External researchers detected and published the malicious release within about 20–26 minutes, followed by CVE assignment, postmortems, and IOC consolidation. The detection / threat-sharing layer is indispensable for scoping and containing impact, and this Brief does not deny that role.

But detection does not change what the receiving side (the npm registry, the CI/CD or developer environment fetching dependencies) actually accepts. In this case the malicious artifact arrived through the legitimate channel bearing a valid OIDC provenance signature, so signature verification passed. The assumption “signed by a trusted publisher = trustworthy artifact” was broken by an in-flight identity hijack. Environments that fetched packages during the tens of minutes before public detection had less reason to suspect the artifacts precisely because the signatures were valid. For regulatory reporting, audit, and litigation, the publisher-identity signature alone is not an independent evidentiary trail that “this artifact is the intended build output.”

Pre-execution attestation takes the design choice of not stopping provenance at the publisher-identity signature: it fixes “this artifact was produced from the intended source, build inputs, and review path” as an independently verifiable cryptographic proof tied to the build’s provenance. If the runner is hijacked during workflow execution, the build-provenance proof is inconsistent, and the receiving side can reject the artifact even when the signature is formally valid. Detection (IOC, anomaly monitoring) and pre-execution attestation (build-provenance proof) are complementary rather than substitutes.

For the detection-vs-attestation thesis, see “The last layer left for cyber defense in the age of AI” (Lemma, 2026-05); for verifying before the action, see “Proof-as-Auth: sign in without ever sending your key” (Lemma, 2026-05).

Response and Industry Response

  • TanStack: published a postmortem and reviewed workflow configuration (specifically pull_request_target handling) and the OIDC publishing path
  • StepSecurity / researchers: detected and disclosed the publishes within 20–26 minutes, sharing IOCs and the list of affected packages
  • npm / GitHub ecosystem: the design around OIDC trusted publishers and Actions cache / trust boundaries surfaced as a live topic. Trusted publishers had been recommended specifically as a countermeasure against token theft, but a new attack surface — runtime hijack of the publisher identity — became visible
  • Cross-industry framing: this incident is part of the “Mini Shai-Hulud” worm and spread to more than 170 packages across npm / PyPI the same day. Abuses of legitimate publishing pipelines continue (e.g., axios, 2026-04). Version-pinning of dependencies and the verification of build provenance — alongside signature verification — emerge as the working agenda

How to verify “was this generated from the intended build provenance?” — not only “was it published via a legitimate signature and legitimate channel?” — is the open question moving forward.

Lemma’s Analysis

Against the detection–proof gap exposed here (provenance assurance stopped at the publisher-identity signature, and the workflow-runtime hijack let malicious artifacts move through with a valid signature still attached), Lemma proposes a design in which provenance is not “the signature of who published this” but rather “this artifact was produced from this source, with these build inputs, via this path” — fixed to the build’s provenance as an independently verifiable cryptographic proof.

  • From signature to provenance: move the basis of provenance from the publisher-identity signature to a cryptographic proof tied to the source, build inputs, and path.
  • Verification before execution: the receiver (CI/CD or developer environment) verifies the proof before pulling the artifact in, and rejects it on inconsistency even when the signature is formally valid.
  • Hijack resistance: even if the OIDC identity is hijacked at runtime, the build-provenance proof signals on a separate channel whether the artifact was produced from the intended build path.
  • Compatibility with existing layers: it does not replace signatures or trusted publishers but layers independent artifact-provenance verification on top of them.

Lemma does not substitute for signatures or trusted publishers; it adds a complementary layer that proves the artifact’s origin alongside the signature that identifies its publisher.

For the design and its scope, see Pillar 01 — Verifiable Origin and Trust402.

Sources

About distribution

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

(c) 2026 FRAME00, INC. — Built for decisions that matter.

Related Briefs
See all 13 in Code Provenance
No. 048 · 2026-06-12

TrapDoor Plants Hidden Directives in AI Assistant Instruction Files Across npm, PyPI, and Crates.io

TrapDoor, disclosed by Socket, is a credential-stealing campaign whose distinctive technique plants invisible directives…

Code Provenance Agent InfrastructureAI Decision Integrity
Brief →
No. 038 · 2026-06-09

IronWorm

When Stolen Credentials Become Publishing Authority (npm Self-Propagating Implant)

Code Provenance Identity & Auth
Brief →
No. 030 · 2026-06-06

Stripe's Trusted API Infrastructure Repurposed to Deliver Card-Skimming Code and Store Stolen Data

Allowlists Trust the Domain's Identity, Not the Provenance of What It Carries

Code Provenance Identity & AuthData Provenance
Brief →
Citation

Cite this Brief

Lemma Critical Team. (2026).
"The TanStack npm Compromise — Malicious Packages Signed Under a Legitimate OIDC Trusted Publisher, Where a Valid Provenance Signature Did Not Mean a Trustworthy Artifact".
Lemma Critical Brief No.014. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/014-tanstack-oidc-trusted-publisher/