The TanStack npm compromise of May 11, 2026 — published research recombined into working tradecraft, weaponized faster than defenders deploy mitigations.
By Thorsten Meyer — May 2026 · Software Security · Part 7
The Vercel forensic case study (Part 6) documented the social/human-supply-chain failure mode — a Roblox cheat script propagating through OAuth trust relationships to compromise platform customer credentials. This piece is the structural counterpart: the technical/CI-CD-architectural failure mode, documented in detail by the TanStack maintainer team within hours of the incident.
On May 11, 2026 — the same day Google Threat Intelligence Group disclosed the first AI-built zero-day in the wild (documented in Part 3) — an attacker published 84 malicious versions across 42 @tanstack/* npm packages in a six-minute window. The publish authenticated via GitHub Actions OIDC trusted-publisher binding for the TanStack/router release workflow. No npm tokens were stolen. The npm publish workflow itself was not compromised. The attacker minted an OIDC token in memory and exfiltrated credentials via Session Protocol — the encrypted messenger network — with no attacker-controlled command-and-control infrastructure to block.
The structural editorial finding: three vulnerabilities were chained, each documented in public security research before the attack:
- The
pull_request_target“Pwn Request” pattern — formally documented by GitHub Security Lab as a dangerous pattern years before 2026 - GitHub Actions cache poisoning across the fork↔base trust boundary — documented by Adnan Khan in May 2024, 12 months before the TanStack attack
- OIDC token extraction from GitHub Actions runner memory — documented by StepSecurity in March 2025, as the tj-actions/changed-files compromise mechanism
Each is necessary for the attack; none alone is sufficient. The chain works because each vulnerability bridges the trust boundary the others assumed. PR fork code crossing into base-repo cache. Base-repo cache crossing into release-workflow runtime. Release-workflow runtime crossing into npm registry write access. Three published research findings. Twelve months between the latest of them and the TanStack incident. Zero novel attacker tradecraft.
This is the research-to-tradecraft compression problem. Every published security research finding becomes attacker tradecraft. The defender’s deployment of mitigations runs slower than the attacker’s composition of published research. The TanStack incident is the canonical 2026 empirical example. Same date as the GTIG zero-day disclosure makes this a remarkable confluence — both events on the same day demonstrating the AI-augmented offensive cascade operating in two different dimensions simultaneously.
The headline finding: the most consequential 2026 supply-chain incidents are no longer technically novel. They are sophisticated compositions of public research, executed faster than the ecosystem’s defensive infrastructure can adapt. The TanStack team — by any measure a competent, security-conscious maintainer group with 2FA enabled across all seven scoped maintainers and OIDC trusted publishing — was compromised through a chain that no individual vulnerability in their stack would have enabled. The composition is the attack surface.
This piece walks the technical chain forensically, situates it in the broader May 2026 supply-chain wave (TanStack is one of 160+ packages compromised in the ongoing Mini Shai-Hulud campaign, alongside Mistral AI, UiPath, Squawk, and others), and extracts the operational lessons for any open-source maintainer or enterprise consumer of the npm ecosystem.
Three public vulnerabilities.
Chained.
The TanStack npm compromise of May 11, 2026 — published research recombined into working tradecraft, weaponized faster than defenders deploy mitigations.
84 malicious versions across 42 packages. Six-minute publish window. No npm tokens stolen. OIDC minted in memory and exfiltrated via Session Protocol. Three vulnerabilities chained — each documented in public research 12-24 months before the attack. Same date as the GTIG zero-day disclosure. The composition is the attack surface.
Each bridges the trust boundary the others assumed.
PR fork code crossing into base-repo cache. Base-repo cache crossing into release-workflow runtime. Release-workflow runtime crossing into npm registry write access. The composition only works because each vulnerability bridges the trust boundary the others assumed.
pull_request_target for fork PRs and checked out the fork’s PR-merge ref to run a build. Bypasses first-time-contributor approval gate. Author attempted trust split but missed that actions/cache@v5‘s post-job save is not gated by permissions:. Cache scope is per-repo, shared across triggers.Linux-pnpm-store-${hashFiles('**/pnpm-lock.yaml')} — exact match. actions/cache@v5 post-step saves poisoned store to that key. Restored entirely as designed when release.yml next runs on push to main.id-token: write for legitimate npm OIDC trusted publishing. Poisoned cache invokes attacker binaries: locate Runner.Worker via /proc/*/cmdline, dump memory via /proc//maps + /proc//mem , extract OIDC token, POST to registry.npmjs.org. Bypasses workflow’s Publish Packages step entirely.The attacker did not invent novel tradecraft. They recombined published research. Verbatim Python script — attribution comment preserved — from the March 2025 tj-actions disclosure. Every defensive research publication becomes attacker reference material within 12-24 months.
Software Supply Chain Defense: Securing Build Environments, Toolchains, and CI/CD Infrastructure Against Advanced Threats
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
May 10 17:16 fork. May 11 19:50 detection.
From the attacker creating a renamed fork (deliberately evading fork-list searches) through the cache poisoning phase, the detonation phase, and the rapid external detection by Ashish Kurmi at StepSecurity. The TanStack postmortem published the complete root cause analysis publicly within hours.
PHASE
65bf499d authored by fabricated identity claude (NOT real Anthropic Claude). [skip ci] prefix suppresses CI on push. Adds packages/history/vite_setup.mjs — ~30,000-line bundled JS payload.PREP
pull_request_target. No first-time-contributor approval — pull_request_target bypasses that gate. pr.yml blocked.TRIGGER
65bf499d on PR head. bundle-size.yml’s benchmark-pr job checks out refs/pull/7378/merge, runs pnpm install + pnpm nx run @benchmarks/bundle-size:build. Executes fork-controlled vite_setup.mjs.EXEC
Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11 (1.1 GB) saved for TanStack/router, scoped to refs/heads/main. Keyed to match what release.yml will compute on next push.ACTIVE
b1c061af). Visible PR diff is 0-file no-op. PR closed and branch deleted in same minute. Cache poison persists. PR appears benign in retrospective review./proc/*/cmdline, dumps memory, extracts OIDC token, POSTs to registry.npmjs.org. Bypasses defined Publish Packages step entirely.EXEC
@tanstack/history@1.161.12 etc. Six minutes between the two publish waves. Workflow status: failure (tests broke; publish still happened).BLAST
DETECTION
COMPLETE
DevOps with GitHub Actions: A Practical Guide to Building Secure, Scalable, and Production-Ready CI/CD Automation Pipelines
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
160+ packages. One worm. Same threat actor.
The TanStack compromise is one node in the broader Mini Shai-Hulud campaign by threat group TeamPCP — the same actor behind LiteLLM PyPI (March 2026), Bitwarden CLI npm, SAP CAP npm, and Lightning PyPI (April 30, 2026). Self-propagating worm pattern. First documented npm worm with valid SLSA Build Level 3 attestations.
May 2026 wave
weekly downloads
compromised May 12
fork → detection
registry.npmjs.org/-/v1/search?text=maintainer: → republish with same injection. Active operational campaign as of May 12, 2026.OIDC token security hardware
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
IOCs · copy-pasteable for hunting queries.
The TanStack postmortem published comprehensive IOCs. Defenders should hunt for these across their environments. The attacker forged a “claude” identity using claude@users.noreply.github.com — not the real Anthropic Claude Code GitHub App. This identity-confusion tactic deserves specific attention in git-log audits.
bun run tanstack_runner.js && exit 1 on install — payload runs, then optional dep “fails” gracefully.router_init.js (~2.3 MB, package root, not in files array). Also: tanstack_runner.js per Socket analysis.https://litter.catbox.moe/h8nc9u.js, https://litter.catbox.moe/7rrc6l.mjs. Secondary exfil via legitimate-looking GitHub GraphQL API traffic.git log --all --author=claude@users.noreply.github.com across all repos. Force-push revert if found.zblgg (id 127806521) · voicproducoes (id 269549300 · account created 2026-03-19 — fresh account, public repos named “A Mini Shai-Hulud has Appeared”). Attacker fork: github.com/zblgg/configuration (renamed). Workflow runs: 25613093674 · 25691781302.
Plustek Duplex Driver License & ID Card Scanner – Bundle Software can Automatically Extracts ID Data and Populates into Data Fields, in Addition to Age Verification. Support Windows only
Amazing and Complete Solution. The included software automatically reads and captures US &Canadian driver license and ID card…
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Installed it? Rotate. Maintain packages? Audit.
Three response tracks. If you installed an affected version on May 11: treat your host as compromised. If you maintain OSS with similar workflow patterns: audit pull_request_target immediately. If you consume the npm ecosystem at enterprise scale: deploy install-time monitoring and lockfile pinning.
- Rotate AWS, GCP, Azure, Kubernetes service-account tokens, Vault tokens, npm
~/.npmrc, GitHub tokens, SSH private keys - Review GitHub Actions runs after 2026-05-11T19:20Z for unexpected npm publish events
- Check outbound connections to
filev2.getsession.org·seed*.getsession.org - Check downstream propagation — if your packages were published during a CI run that installed compromised version, those may also be compromised
- Audit
~/.claude/+.vscode/tasks.json· removerouter_runtime.js,setup.mjs git log --all --author=claude@users.noreply.github.com· revert if found- Run
npm token list· revoke unrecognized tokens
- Audit pull_request_target workflows immediately · never check out fork-submitted code without explicit approval gates
- Pin third-party action refs to commit SHAs ·
actions/checkout@8e5e7e5ab8...not@v6 - Separate cache scopes for trusted vs untrusted contexts · explicit
restore-keysandkeypatterns - Consider moving from OIDC trusted publisher to short-lived classic tokens with manual review
- Add internal alerting on npm publishes · fire on any publish that doesn’t originate from expected workflow step
- Audit other repos for the same bundle-size.yml-style pattern
- Restrict
id-token: writeto only the publish step that needs it
- Deploy npm package monitoring at install time · Socket / StepSecurity / Snyk · Socket flagged TanStack in 6 minutes
- Lockfile-pinned dependencies don’t auto-pull new versions · only consumers installing during the publish window were affected
- Audit lockfiles for
github:URLoptionalDependencies· unusual for production deps, exact pattern used here - CI/CD secret rotation automation · 30-90 day schedule regardless of incident status
- Treat provenance attestations as one layer, not sole verification · Mini Shai-Hulud produces valid Build L3 attestations on malicious packages
- Establish IR playbooks for OSS supply-chain compromise scenarios
Three pieces of public security research. Twelve months between the latest and the attack. Zero novel attacker tradecraft. A competent maintainer team with 2FA and OIDC trusted publishing — compromised through a chain that no individual vulnerability in their stack would have enabled. The composition is the attack surface.
I · The forensic timeline · 28 hours from fork to detection
Reconstructing the chain from the TanStack postmortem by Tanner Linsley, StepSecurity analysis by Ashish Kurmi, Socket research, and the official GitHub Security Advisory GHSA-g7cv-rxg3-hmpx. All times UTC unless noted.
May 10, 17:16 · Attacker creates the fork
The attacker — GitHub user zblgg (account ID 127806521) — created github.com/zblgg/configuration as a fork of TanStack/router. The fork was deliberately renamed to evade GitHub’s fork-list search functionality. A defender attempting to enumerate forks of TanStack/router by name would not have surfaced this one. The renaming is operational tradecraft — not novel, but deliberate.
May 10, 23:29 · The malicious commit lands on the fork
Commit 65bf499d16a5e8d25ba95d69ec9790a6dd4a1f14 was authored on the fork. The commit author identity was fabricated: claude . This is not the real Anthropic Claude Code GitHub App — it uses a forged identity designed to exploit GitHub’s email-display logic and create plausible attribution confusion. Subsequent forensic recommendations include git-log searching for this fabricated author: git log --all --author=claude@users.noreply.github.com to locate any commits the attacker may have placed in other repositories via the same identity.
The commit added a single file: packages/history/vite_setup.mjs — a ~30,000-line bundled JavaScript payload. The commit message was prefixed with [skip ci] to suppress CI execution on the push event. The commit existed but was not yet invoked.
A separate orphan commit — 79ac49eedf774dd4b0cfa308722bc463cfe5885c — was placed in the fork’s git object store via a second attacker account, voicproducoes (ID 269549300, account created 2026-03-19). This orphan commit contains the post-execution payload that gets fetched via the malicious optionalDependencies injection. voicproducoes had public repositories named “A Mini Shai-Hulud has Appeared” — operational branding signaling connection to the broader campaign.
May 11, 10:49 · PR #7378 opens against TanStack/router#main
Pull request titled “WIP: simplify history build” opened by zblgg. Two GitHub Actions workflows configured with pull_request_target triggered automatically: bundle-size.yml and labeler.yml. Critically, pull_request_target bypasses GitHub’s first-time-contributor approval gate. A separate workflow, pr.yml (configured with pull_request), did not run — blocked pending approval that never came.
This is the structural reason pull_request_target is dangerous. The trigger was designed for use cases that need access to base-repo secrets (labeling, automated responses), but it executes with base-repo permissions even on fork-submitted code. A first-time contributor’s PR can invoke base-repo workflows that bypass review.
May 11, 11:01-11:11 · Multiple force-pushes
The attacker force-pushed the PR head multiple times, each triggering more pull_request_target runs. The 11:11 force-push landed 65bf499d — the malicious commit — on the PR head. The bundle-size.yml workflow’s benchmark-pr job checked out refs/pull/7378/merge, ran pnpm install and pnpm nx run @benchmarks/bundle-size:build. This executed the fork-controlled vite_setup.mjs payload.
May 11, 11:29 · The cache poison persists
The malicious payload’s purpose was specifically to poison the GitHub Actions cache. It wrote data into the pnpm-store directory under a deliberately-computed key: Linux-pnpm-store-${hashFiles('**/pnpm-lock.yaml')} — the exact key the legitimate release.yml workflow would compute and look up on the next push to main.
When the benchmark-pr job ended, actions/cache@v5‘s post-step automatically saved the (now-poisoned) pnpm store to that exact key. Cache entry Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11 (~1.1 GB) was saved for TanStack/router, scoped to refs/heads/main. The cache poison persists across workflow runs.
May 11, 11:31 · Cleanup · attacker covers tracks
The attacker force-pushed the PR back to current main HEAD (b1c061af), making the visible PR diff a 0-file no-op. PR was closed and the branch deleted in the same minute. The cache poison persists. The PR appears clean. A defender reviewing the closed PR after the fact would see no malicious code — only a no-op force-push and a cleanup.
May 11, 19:15 · Detonation begins
Manuel (TanStack maintainer) merged PR #7369 (Shkumbin’s CSS.supports fix) → push to main triggered release.yml. Workflow run 25613093674 started at 19:15:44. Same poisoned pnpm cache was restored. The malicious code now ran inside the release workflow’s runtime context.
May 11, 19:20:39 · The first publish wave
Eighty-four versions across 42 packages were published. The publish authenticated via OIDC trusted-publisher binding for TanStack/router release.yml@refs/heads/main — but it did not come from the workflow’s defined Publish Packages step, which was skipped because tests had failed. It came from the malware running during the test/cleanup phase.
The malicious code’s specific technique:
- Locate the GitHub Actions Runner.Worker process via
/proc/*/cmdline - Read
/proc/and/maps /proc/to dump the worker process memory/mem - Extract the OIDC token which the runner mints lazily, in memory, when
id-token: writepermission is set - POST directly to
registry.npmjs.orgusing the extracted token — bypassing the workflow’s defined publish step entirely
The release workflow status: failure. But the malicious publish had already completed during the failed run. The mechanism is the same memory-extraction technique used in the tj-actions/changed-files compromise of March 2025 — verbatim Python script, with the attribution comment preserved. The attacker did not invent novel tradecraft. They reused published research.
May 11, 19:26:14 · The second publish wave
Manuel merged PR #7382 (jiti tsconfig paths fix) → second push to main triggered release.yml. Workflow run 25691781302 started at 19:16:22. Same poisoned cache restored. Second-version-per-package set published — @tanstack/history@1.161.12 etc. — at 19:26:14. Six minutes between the two publish waves.
May 11, ~19:50 · External detection
Ashish Kurmi at StepSecurity opened tracking issue #7383 with complete technical analysis. Socket flagged every malicious version within six minutes of publication per Socket’s threat-research disclosure. The detection community had a public IOC pattern within minutes. Detection-to-issue-filing latency was approximately 20 minutes.
Tanner Linsley (TanStack maintainer) received a phone call from Socket.dev “just moments after starting the war room.” This is operationally significant — the security ecosystem’s monitoring infrastructure caught the compromise faster than the maintainer team’s own internal alerting (which did not exist for this scenario).
May 11, ~20:00-21:30 · Incident response
War room activation. Manuel removed all other team push permissions on GitHub (precaution against compromised maintainer machines). Tanner emailed security@npmjs.com with full IOC list. Comprehensive scan of all 295 @tanstack/* packages confirmed scope at 42 packages, 84 versions. Public disclosure via @tan_stack Twitter/X/LinkedIn/Bluesky. Investigation identified the bundle-size.yml cache-poisoning vector and the zblgg/configuration fork. All cache entries for all TanStack/* GitHub repositories purged via API. Hardening PR merged. GitHub Security Advisory GHSA-g7cv-rxg3-hmpx published. CVE requested.
II · The three-vulnerability composition · structural analysis
The TanStack postmortem is unusual in its technical depth — the maintainer team published the full root-cause analysis publicly within hours. The structural argument it makes is the editorial centerpiece of this piece:
Vulnerability 1 · The pull_request_target “Pwn Request” pattern
The bundle-size.yml workflow ran pull_request_target for fork PRs and, inside that trigger context, checked out the fork’s PR-merge ref and ran a build:
on:
pull_request_target:
paths: ['packages/**', 'benchmarks/**']
jobs:
benchmark-pr:
steps:
- uses: actions/checkout@v6.0.2
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: TanStack/config/.github/setup@main
- run: pnpm nx run @benchmarks/bundle-size:build
The author of the workflow had attempted a trust split. The comment-pr job was separate from benchmark-pr, with a YAML comment noting the intent to keep benchmark-pr “untrusted with read-only permissions.” The split was correct in principle but missed two specific facts:
actions/cache@v5‘s post-job save is not gated bypermissions:. Cache writes use a runner-internal token, not the workflowGITHUB_TOKEN. Settingpermissions: contents: readdoes not block cache mutation.- Cache scope is per-repo, shared across
pull_request_targetruns (which use the base repo’s cache scope) and pushes to main. A PR running in the base repo’s cache scope can poison entries that production workflows on main will later restore.
This is the GitHub Security Lab Pwn Request research — years of public documentation, formal recommendations, and example code for safe alternatives. The pattern is not subtle. The defensive guidance is explicit. The TanStack workflow contained the pattern anyway.
Vulnerability 2 · Cache poisoning across trust boundaries
The malicious vite_setup.mjs was specifically designed to write data into the pnpm-store directory under a key the legit release.yml workflow would compute and look up: Linux-pnpm-store-${hashFiles('**/pnpm-lock.yaml')}. When the benchmark-pr job ended, actions/cache@v5‘s post-step saved the (now-poisoned) pnpm store to that exact key.
When release.yml next ran on a push to main, its Setup Tools step restored the poisoned entry — entirely as designed. This is the class of attack documented in Adnan Khan’s May 2024 research: “The Monsters in Your Build Cache.” Not a TanStack-specific bug. A known GitHub Actions architectural property that requires conscious mitigation.
Adnan Khan’s research was published 12 months before the TanStack attack. During those 12 months, GitHub Actions cache scoping behavior did not change. The recommended mitigations (separate cache keys for trusted vs. untrusted contexts, explicit cache namespacing per workflow trigger) require maintainer awareness and deliberate workflow restructuring. TanStack — and presumably thousands of other npm-published OSS projects — had not undertaken this work.
Vulnerability 3 · OIDC token extraction from runner memory
release.yml declared id-token: write (legitimately needed for npm OIDC trusted publishing). When the poisoned pnpm store was restored on the runner, attacker-controlled binaries were now on disk and got invoked during the build step. The technique:
- Locate the GitHub Actions
Runner.Workerprocess via/proc/*/cmdline - Read
/proc/and/maps /proc/to dump the worker’s memory/mem - Extract the OIDC token (minted lazily in memory when
id-token: writeis set) - Use the token to authenticate
POSTrequests directly toregistry.npmjs.org— bypassing the workflow’sPublish Packagesstep entirely
This is the same memory-extraction technique used in the tj-actions/changed-files compromise of March 2025. The TanStack postmortem explicitly notes that the verbatim Python script (with attribution comment preserved) was reused. The attacker did not invent the technique. They copied it.
Why each vulnerability is necessary
The TanStack postmortem makes the structural argument explicit:
pull_request_targetalone is fine for trusted operations (labeling, comments) — it’s the combination with checking out untrusted fork code that creates the failure mode- Cache poisoning alone (from inside an already-compromised dependency) requires a separate publish vehicle to monetize
- OIDC token extraction alone requires existing code execution on the runner
The chain only works because each vulnerability bridges the trust boundary the others assumed. PR fork code crossing into base-repo cache (vulnerability 1). Base-repo cache crossing into release-workflow runtime (vulnerability 2). Release-workflow runtime crossing into npm registry write access (vulnerability 3). Each transition was an architectural assumption about trust boundaries that turned out to be false in composition.
The research-to-tradecraft compression
The structurally important property of this attack: every component was publicly documented before the attack. Specifically:
pull_request_targetPwn Request pattern — GitHub Security Lab formal documentation predates the attack by years- Cache poisoning across trust boundaries — Adnan Khan’s research published May 2024, 12 months before TanStack
- OIDC token extraction from runner memory — StepSecurity tj-actions writeup published March 2025, 14 months before TanStack
The defender’s deployment of mitigations runs slower than the attacker’s composition of published research. This is the structural pattern that makes TanStack-class compromises predictable rather than exceptional. The next attack will reuse the same components against a different maintainer who hasn’t yet deployed mitigations. The composition is the threat surface, not any individual vulnerability.
III · The Mini Shai-Hulud campaign · TanStack as one node in a broader pattern
The TanStack compromise is not isolated. It is part of the Mini Shai-Hulud campaign — the self-propagating npm worm pattern named after the September 2025 Shai-Hulud npm worm (which compromised 500+ versions across hundreds of packages). The 2026 evolution adds CI/CD secret theft and OIDC-based trusted-publishing abuse as propagation mechanisms.
Same threat actor · TeamPCP
StepSecurity’s analysis attributes the TanStack compromise to TeamPCP — the same threat group I documented in Part 4 (OAuth Permission Apocalypse) and Part 5 (ShinyHunters · The New APT Model) as UNC6780. Prior TeamPCP operations:
- LiteLLM PyPI · March 24, 2026 — malicious versions 1.82.7 and 1.82.8 published using stolen Trivy CI/CD credentials. SANDCLOCK credential stealer in 3.4 million daily downloads
- Bitwarden CLI npm — earlier 2026 compromise
- SAP CAP npm packages — earlier 2026 compromise
- Lightning AI PyPI · April 30, 2026 — versions 2.6.2 and 2.6.3 compromised
The May 2026 wave extending through TanStack is structurally the same operation. The same threat group is iterating on the same playbook against multiple package ecosystems. The TanStack attack is a refinement of the same template: CI/CD compromise → trusted-publisher abuse → self-propagation via maintainer search.
Self-propagation · the worm mechanism
The TanStack payload’s self-propagation logic:
GET registry.npmjs.org/-/v1/search?text=maintainer:
For each victim’s other published packages, the payload republishes them with the same injection. This is the worm mechanism. A single maintainer’s CI/CD compromise propagates across every package they maintain. Multiple maintainers compromised through cascading installs propagate across multiple package ecosystems.
The Mini Shai-Hulud campaign’s documented scope as of May 12, 2026 (when this piece is being written, less than 24 hours after the TanStack disclosure):
- 160+ packages compromised across the May 2026 wave per Aikido Security tracking
- 42 TanStack packages in the May 11 publish (84 versions total)
@tanstack/react-routerhas 12+ million weekly downloads — the canonical example of massive blast radius- Cascade beyond TanStack to UiPath, Squawk, Mistral AI, DraftLab — packages from completely separate maintainer organizations
- Intercom-client@7.0.4 compromised May 12 — 361,510 weekly downloads — via the worm propagation through stolen CI/CD secrets
The campaign is operationally active as this piece is published. More compromised packages will be identified in the days and weeks ahead. Each compromised package extends the worm’s reach into another maintainer’s CI/CD infrastructure, which the worm uses to compromise more packages.
The SLSA Build Level 3 attestation problem
The most structurally significant property of the Mini Shai-Hulud campaign: the malicious packages carry valid SLSA Build Level 3 provenance attestations. Per StepSecurity:
“This is the first documented npm worm that produces validly-attested malicious packages. The attacker used stolen OIDC tokens with the legitimate Sigstore stack to produce valid Build Level 3 attestations for malicious packages.”
This is a critical breakage of an emerging defensive infrastructure. SLSA provenance attestations were designed to provide a cryptographic guarantee that a package was built by the workflow that claims to have built it. When the attacker successfully publishes through the workflow’s own OIDC token, the resulting attestations are technically valid — they correctly attest that the malicious package was built by TanStack/router release.yml@refs/heads/main. The attestation is true. The package is malicious.
The defensive implication: provenance attestations alone do not validate package safety. They validate that a package came from a specific workflow. When the workflow is compromised — as in TanStack’s case — the attestation becomes attacker-validated rather than defender-validated. npm audit signatures will pass for the malicious TanStack versions. Downstream consumers relying on provenance verification as their security mechanism have no signal that the packages are malicious.
This needs to be internalized across the npm ecosystem. SLSA provenance is one of multiple defense layers, not a single sufficient mechanism. The Mini Shai-Hulud campaign has demonstrated empirically that workflow compromise produces valid attestations on malicious packages. Defense-in-depth applies; provenance alone does not.
IV · The IOC reference · what defenders should hunt for
The TanStack postmortem published comprehensive indicators of compromise. Defenders should hunt for these across their environments:
In any @tanstack/* package’s manifest:
"optionalDependencies": {
"@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
}
File system indicators:
router_init.js(~2.3 MB, in package root, not declared infilesarray)tanstack_runner.js(the named payload per Socket analysis)- Persistence hooks in
~/.claude/directories (note: the attacker’sclaudeidentity is fabricated, not real Claude Code) — checksettings.jsonhooks - Persistence hooks in
.vscode/tasks.jsonconfigurations - Files
router_runtime.js,setup.mjsin project roots
Cache indicators:
- GitHub Actions cache key:
Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11
Network indicators:
- 2nd-stage payload URLs:
https://litter.catbox.moe/h8nc9u.js,https://litter.catbox.moe/7rrc6l.mjs - Exfiltration network:
filev2.getsession.org,seed1.getsession.org,seed2.getsession.org,seed3.getsession.org(Session Protocol — end-to-end encrypted, blocking by IP/domain is the only mitigation since there’s no attacker-controlled C2) - Secondary exfiltration: GitHub GraphQL API (legitimate-looking traffic to
api.github.com) - Self-propagation queries:
registry.npmjs.org/-/v1/search?text=maintainer:*
Identity indicators:
- Forged commit author:
claude— git-log search:git log --all --author=claude@users.noreply.github.com - Real attacker accounts:
zblgg(ID 127806521),voicproducoes(ID 269549300, account created 2026-03-19) - Attacker fork:
github.com/zblgg/configuration(renamed fork of TanStack/router to evade fork-list searches) - Orphan payload commit:
79ac49eedf774dd4b0cfa308722bc463cfe5885c
Workflow run indicators:
github.com/TanStack/router/actions/runs/25613093674(attempt 4) — first malicious publishgithub.com/TanStack/router/actions/runs/25691781302— second malicious publish
V · The defensive lessons · operational guidance
For npm consumers, open-source maintainers, and enterprise security teams, the TanStack incident produces specific operational guidance:
For anyone who installed an affected @tanstack/* version on May 11, 2026
The TanStack postmortem is explicit: treat the install host as potentially compromised. Required actions:
- Rotate all reachable credentials — AWS, GCP, Azure, Kubernetes service-account tokens, Vault tokens, npm tokens (
~/.npmrc), GitHub tokens (env,ghCLI,.git-credentials), SSH private keys - Review GitHub Actions runs that occurred after the compromised versions were published (after 2026-05-11T19:20Z). Look for unexpected npm publish events and outbound connections to
filev2.getsession.orgorseed*.getsession.org - Check downstream propagation — if any of your packages were published during a CI run that installed a compromised version, those published versions may also be compromised. The worm uses OIDC token exchange to publish to any package the pipeline has access to
- Audit
.claude/and.vscode/directories in all developer home directories and project roots. Removerouter_runtime.js,setup.mjs, and any unfamiliar entries insettings.jsonhooks ortasks.json - Review recent commits to your GitHub repositories for the author
claude@users.noreply.github.com— git-log search and force-push revert if found
For open-source maintainers using GitHub Actions
The TanStack postmortem’s structural recommendations:
Audit pull_request_target workflows immediately. Per GitHub Security Lab guidance: pull_request_target workflows should never check out fork-submitted code without explicit approval gates. If a workflow needs to run against fork code (benchmarks, tests), use pull_request with explicit pull_request_target separation for the trusted operations (labels, comments). The trust split must be enforced at the trigger level, not within job permissions.
Pin third-party action references to commit SHAs. Floating refs like @v6.0.2 or @main create standing supply-chain risk independent of any specific incident. Pin to immutable SHAs: uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab rather than uses: actions/checkout@v6. The TanStack postmortem explicitly identifies this as a hardening gap they had not closed.
Implement separate cache scopes for trusted vs. untrusted contexts. Cache key namespacing should distinguish PR-context caches from main-context caches. Adnan Khan’s research provides specific guidance: explicit restore-keys and key patterns that prevent cross-context restoration.
Move from OIDC trusted-publisher binding to short-lived classic tokens with manual review. This is the TanStack team’s explicit post-incident recommendation. OIDC trusted publishing has no per-publish review — once configured, any code path in the workflow can mint a publish-capable token. Short-lived classic tokens with manual review reintroduce the human-in-the-loop check that OIDC eliminated.
Add provenance-source verification. The next step beyond SLSA Build Level 3 is verifying that publishes come from expected workflow steps, not arbitrary code execution within the workflow. This requires tooling that doesn’t yet exist in production form, but the architectural direction is clear.
Implement internal alerting on publishes. The TanStack team learned of the compromise from a third party. Internal alerting that fires on any npm publish event — particularly publishes that don’t originate from the expected workflow step — would have caught this within seconds rather than 20 minutes.
For enterprise consumers of the npm ecosystem
Deploy npm package monitoring at install time. Socket, StepSecurity, Snyk, and similar tools provide real-time scanning of npm packages during install operations. Socket flagged the TanStack compromises within six minutes; enterprise consumers with Socket integration would have been alerted before most affected versions reached production environments.
Implement npm install pinning at the lockfile level. Lockfile-pinned dependencies don’t automatically pull new versions. The TanStack compromise primarily affected consumers who installed during the May 11 publish window. Lockfile-pinned consumers were not affected until they ran npm update or equivalent.
Audit for optionalDependencies patterns referencing git URLs. The malicious @tanstack/setup injection used github:tanstack/router# — a git URL pattern that legitimately exists but is unusual for production dependencies. Auditing for git URL references in lockfiles surfaces this pattern.
Establish CI/CD secret rotation automation. The Mini Shai-Hulud campaign specifically targets CI/CD secrets. Rotation schedules of 30-90 days regardless of incident status reduce the operational utility of any specific theft event. Combine with OIDC where possible (which has its own attack surface but reduces the long-tail of static-credential theft).
Treat published research as future attacker tradecraft. This is the structural lesson. Every defensive research publication becomes attacker reference material within 12-24 months. Defenders who do not deploy mitigations within the same window operate against the next composition of the research. The TanStack incident is the empirical proof of this pattern.
VI · The structural close · what this incident represents
The TanStack npm compromise of May 11, 2026 is structurally important not because of its specific blast radius (significant but containable through deprecation, IOC publication, and the security community’s rapid response) but because it crystallizes the research-to-tradecraft compression problem in a single forensically-documented incident.
Three pieces of published security research. Twelve months between the latest of them and the attack. Zero novel attacker tradecraft. A competent, security-conscious maintainer team with 2FA enabled and OIDC trusted publishing configured — compromised through a chain that no individual vulnerability in their stack would have enabled. The composition is the attack surface.
Same date as the GTIG zero-day disclosure makes this a remarkable confluence. Both events on May 11, 2026 demonstrate the AI-augmented offensive cascade operating in two different dimensions simultaneously. The GTIG case was AI-discovered novel vulnerability in legitimate software. The TanStack case was AI-augmented composition of published research into operational tradecraft. Both are now operational threats. The defensive infrastructure has not yet adapted to either.
For the broader npm and open-source ecosystem, the Mini Shai-Hulud campaign demonstrates the structural maturity of self-propagating supply-chain malware. The worm mechanism operates through maintainer-search and OIDC-token-extraction at a scale that produces 160+ compromised packages across multiple maintainer organizations within a single campaign wave. TanStack is one node. UiPath is another. Mistral AI is another. The campaign extends as long as compromised packages reach maintainer machines and CI/CD pipelines that have publish access to additional packages.
The defensive infrastructure required to close this gap is substantial:
- Pwn Request elimination across the OSS ecosystem — every
pull_request_targetworkflow that checks out fork code is a potential TanStack-style entry vector - Cache scope separation in GitHub Actions — the architectural property requires deliberate workflow restructuring at scale across thousands of OSS projects
- OIDC trusted-publisher review mechanisms — the technology that GitHub and npm shipped requires layered controls that don’t yet exist in production
- Provenance verification beyond Build Level 3 — workflow-step-level verification, not just workflow-identity verification
- Real-time npm publish monitoring — Socket-class capability deployed at scale across maintainer and consumer organizations
None of this exists comprehensively as of May 2026. Each individual defensive element exists in tooling somewhere. The aggregate defensive infrastructure that would close the structural gap does not.
Every npm publish is a potential TanStack-class incident in waiting. The same vulnerabilities exist across thousands of OSS projects with similar workflow patterns. The same threat actor (TeamPCP) continues operating. The same campaign (Mini Shai-Hulud) continues propagating. The next attack will use the same composition against a different target.
The TanStack maintainer team’s response — comprehensive postmortem within hours, IOC publication, hardening PR merged same day, public disclosure across multiple channels — is the model for how OSS supply-chain incident response should operate. The ecosystem benefits enormously from this level of transparency. Other maintainers facing similar incidents should adopt the same playbook.
But the structural problem is upstream of any individual incident response. The npm ecosystem, GitHub Actions architecture, and SLSA provenance infrastructure produce TanStack-class incidents as predictable outputs of their current design. Each individual hardening (admin-managed consent in Google Workspace, Pwn Request elimination in GitHub Actions, OIDC provenance verification in npm) reduces the probability of incidents at the margin. None of them eliminates the class.
That’s the canonical 2026 supply-chain security finding. The composition is the attack surface. The defensive infrastructure addresses individual vulnerabilities. The aggregate gap remains open. Whether the gap closes faster than the threat actors’ composition velocity is the structural question of 2026-2027.
That’s the read on where we are. The franchise will continue tracking these incidents as they emerge — TanStack is the May 11 case; June, July, August will produce more. The pattern is operational and the documentation is necessary.
About the Author
Thorsten Meyer is a Munich-based futurist, post-labor economist, and recipient of OpenAI’s 10 Billion Token Award. He spent two decades managing €1B+ portfolios in enterprise ICT before deciding that writing about the transition was more useful than managing quarterly slides through it. More at ThorstenMeyerAI.com.
Related Reading · the software security franchise
- 732 Bytes to Root · the cost-curve collapse · Part 1
- The 90-Day Window Closed · the disclosure collapse · Part 2
- The Defender’s Counter-Cascade · the deployment gap · Part 3
- The OAuth Permission Apocalypse · “Allow All” is the new SQL injection · Part 4
- ShinyHunters · The New APT Model · Part 5
- The Roblox Cheat That Broke Vercel · the human supply-chain failure · Part 6
Sources
- TanStack · Tanner Linsley · Postmortem: TanStack npm supply-chain compromise · May 11, 2026
- GitHub Security Advisory · GHSA-g7cv-rxg3-hmpx
- Tracking issue · TanStack/router#7383 · opened by ashishkurmi at 19:50 UTC May 11
- StepSecurity · Ashish Kurmi · TeamPCP’s Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Compromises TanStack npm Packages
- Socket · TanStack npm Packages Compromised in Ongoing Mini Shai-Hulud Supply-Chain Attack
- Socket Twitter announcement · 6-minute flagging time per malicious version
- Aikido Security · Mini Shai-Hulud Is Back: npm Worm Hits over 160 Packages, including Mistral and Tanstack
- Cyber Kendra · TanStack Packages Hit by Sophisticated Supply Chain Attack
- Adnan Khan · The Monsters in Your Build Cache: GitHub Actions Cache Poisoning · May 2024
- GitHub Security Lab · Keeping your GitHub Actions and workflows secure: Preventing pwn requests
- StepSecurity · Harden-Runner detection: tj-actions/changed-files action is compromised · March 2025 — verbatim OIDC memory extraction technique reused in TanStack attack
- TeamPCP threat group continuity · LiteLLM PyPI March 24 2026 · Bitwarden CLI npm · SAP CAP npm · Lightning PyPI April 30 2026
- npm policies · Unpublish · Provenance
- Mini Shai-Hulud campaign · Socket supply chain attacks tracking
- Historical precedent · Shai-Hulud npm worm September 2025 · 500+ versions across hundreds of packages
- IOC · OAuth optional dependency injection
@tanstack/setupgithub:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c - IOC · Cache key
Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11 - IOC · Exfiltration
filev2.getsession.org·seed{1,2,3}.getsession.org· Session Protocol E2E encrypted - IOC · Forged commit author
claude· NOT real Anthropic Claude Code GitHub App - IOC · Attacker accounts
zblgg(127806521) ·voicproducoes(269549300 · created 2026-03-19) - IOC · Renamed fork
github.com/zblgg/configuration
