By ByteBot
A security company just had 170 private GitHub repositories stolen — and the root cause was a poisoned npm package installed on a former employee’s laptop four months ago. The TanStack supply chain attack hit on May 11. The damage is still arriving.
Last week, CrowdSec disclosed that attackers had silently copied its private source code using a GitHub OAuth token harvested from a compromised developer machine. The theft traced directly to the TanStack npm compromise. Here is what happened, why it matters, and what you need to check in your own environment.
What Happened on May 11
Between 19:20 and 19:26 UTC on May 11, 2026, an attacker published 84 malicious versions across 42 @tanstack/* packages on npm — in a six-minute window. The malicious versions were detected within 26 minutes by an external researcher and deprecated within the hour. Most developers never consciously installed them. Plenty of CI pipelines did.
The attack exploited a GitHub Actions cache poisoning pattern that has been documented for years. The attacker opened a pull request against TanStack’s fork, triggering a pull_request_target workflow. Because this workflow type runs in the context of the base branch, it shares a cache namespace with production release workflows. The attacker poisoned that shared cache with a malicious pnpm store. When TanStack’s legitimate release workflow ran next, it restored from the poisoned cache and executed attacker-controlled code — which extracted an OIDC token from the runner’s memory and used it to publish malicious packages as a legitimate TanStack maintainer.
This is not a zero-day. It is an architectural trust boundary issue that GitHub has not fixed at the platform level, though a community discussion is open.
What the Malware Stole
The Mini Shai-Hulud payload targeted everything a developer machine might have. AWS Instance Metadata Service tokens, GCP metadata, Azure credentials, GitHub OAuth tokens, SSH private keys, npm tokens from ~/.npmrc, Kubernetes service account material, HashiCorp Vault tokens, and AI tool API keys. On CI machines, it went further — GitHub Actions OIDC tokens, CircleCI credentials, and package registry signing tokens.
The worm component propagated to over 160 additional npm and PyPI packages using stolen maintainer tokens. According to Snyk, @tanstack/react-router alone has 12 million weekly downloads. The blast radius was real.
The CrowdSec Case Study: 117 Days Undetected
The attack was detected in 26 minutes. The breach it enabled at CrowdSec went undetected for 117 days. That gap is instructive.
A former CrowdSec employee had a compromised @tanstack/* package installed during the May 11 window. The malware harvested a GitHub OAuth token from that machine. On May 22 — eleven days after the npm attack — an attacker used that token to clone approximately 170 of CrowdSec’s private GitHub repositories, including its SaaS console code, data science models, and deployment automation.
CrowdSec removed the former employee’s account from its GitHub organization on May 25, three days after the theft. The stolen code surfaced on a cybercrime forum on September 16 — 128 days after the original attack.
CrowdSec is a security company. The lesson is not that they were negligent — it is that this attack class is designed to be slow. The credential theft happens in minutes. The exploitation can happen days or weeks later. Discovery can be months out.
Are You Affected?
Check your package-lock.json or yarn.lock for these versions, published on May 11, 2026:
@tanstack/react-router: 1.169.5, 1.169.8@tanstack/router-core: 1.169.5, 1.169.8@tanstack/vue-router: 1.169.5, 1.169.8@tanstack/solid-router: 1.169.5, 1.169.8@tanstack/react-start: 1.167.68, 1.167.71@tanstack/router-plugin: 1.167.38, 1.167.41
If any of these were installed on a machine between May 11 and May 13, treat that machine as compromised and rotate everything accessible from it: GitHub tokens, AWS keys, SSH keys, npm tokens, cloud credentials. Also block these at DNS or proxy level: git-tanstack.com, *.getsession.org, 83.142.209.194.
Fix Your CI Pipelines
The underlying GitHub Actions issue is fixable today. For any project using pull_request_target:
- Set
cache: falseon any job that processes pull request input from fork branches - Scope cache keys to
github.ref— never restore across fork/base trust boundaries - Pin all GitHub Actions to full 40-character commit SHAs, not version tags
- Run zizmor — a static analyzer that catches dangerous
pull_request_targetpatterns in workflow files - Scope
GITHUB_TOKENpermissions minimally; avoidid-token: writeunless the workflow genuinely needs it
The Lesson That Keeps Costing People
The CrowdSec breach had a kill switch at each stage: rotate the GitHub token on May 11, revoke ex-employee access on their last day, scope tokens so a former employee’s machine cannot read 170 private repos. None of those things are hard.
The Wiz analysis of Mini Shai-Hulud was published in May. OpenAI disclosed its two affected devices and rotated certificates within days. CrowdSec’s disclosure came four months later because no one was watching for slow-burn credential use by an account that should have been deprovisioned.
Supply chain attacks are not a May 11 problem. They are a right-now problem if you have not checked your lockfiles, rotated your tokens, and confirmed that former employees can no longer access your repositories.
