TanStack Was Not the Whole Story: Mini Shai-Hulud Was an npm/PyPI Supply-Chain Worm

This article is based on public reporting available as of 2026-05-13. Mini Shai-Hulud is still an actively tracked campaign, so affected packages and IOCs (indicators of compromise) may change.

In May 2026, a supply-chain compromise was reported across TanStack's npm packages. Malicious versions were published for 42 @tanstack/* packages, and installing those versions triggered a credential stealer.

If you look only at TanStack, the incident can seem like a single npm compromise. But when you read The Hacker News coverage and the analyses from StepSecurity and Socket, it is better understood as part of a broader self-propagating supply-chain campaign called Mini Shai-Hulud.

The important point is that this was not just "a dependency package was compromised." It was closer to a worm that used developer machines and CI/CD environments as stepping stones to reach the next maintainer and the next package ecosystem.

What happened at TanStack

According to the TanStack GitHub Advisory, malicious versions were published to the npm registry for 42 @tanstack/* packages, totaling 84 versions, between 2026-05-11 19:20 and 19:26 UTC. The issue is tracked as CVE-2026-45321 with a CVSS score of 9.6.

The publish was authenticated through the legitimate GitHub Actions OIDC trusted-publisher binding. At the same time, the advisory explains that the publish workflow itself was not modified.

This section is based on TanStack's official postmortem and GitHub Advisory:

At a high level, the TanStack-specific path looked like this:

TanStack-specific path:

checkout and build fork PR code inside pull_request_target
  + GitHub Actions cache poisoning
  + OIDC token extraction from the Actions runner process
  -> malicious publish that looked like it came from the legitimate release path

The issue was not simply the use of pull_request_target. The problem was that the workflow checked out and executed untrusted fork PR code inside a pull_request_target workflow. pull_request_target runs in the context of the base repository, so it should generally be limited to operations that do not execute the contents of the PR, such as labeling or commenting.

TanStack's postmortem explains that bundle-size.yml ran on pull_request_target, checked out the fork PR merge ref, and ran a build for bundle-size measurement. In other words, untrusted fork PR code ran within the base repository's cache scope. That became the entry point for cache poisoning.

Using similar cache keys between test and release workflows is not unusual by itself. For example, caching a pnpm store based on the hash of pnpm-lock.yaml is a common CI optimization.

The problem is when a cache touched by untrusted PR code can also be restored by the release workflow. A cache is not executed just because it is restored. But if the release workflow later runs pnpm install or a build step that references dependencies or binaries from the restored pnpm store, attacker-controlled code placed there can be invoked.

Using the same cache key:
  common

Letting release restore a cache created by untrusted PR code:
  should not happen

In the TanStack case, a malicious script executed from the fork PR poisoned the pnpm store. The actions/cache post-job save then stored that pnpm store. Later, a release workflow triggered by a push to main restored the same cache. During build, test, or cleanup work, attacker-controlled binaries were invoked, leading to OIDC token extraction and a direct publish to npm.

The malicious package versions included an obfuscated JavaScript payload called router_init.js, roughly 2.3 MB in size. It ran during install and collected AWS IMDS credentials, GCP metadata, Kubernetes service-account tokens, Vault tokens, npm tokens from ~/.npmrc, GitHub tokens, SSH private keys, and more.

That explains how the TanStack release pipeline was abused. But Mini Shai-Hulud becomes more concerning when you look beyond TanStack.

It was not only TanStack

The Hacker News article lists package compromises associated with TeamPCP that went beyond TanStack, including UiPath, Mistral AI-related packages, OpenSearch, and Guardrails AI across npm and PyPI.

Socket also tracked additional compromised artifacts after the initial TanStack reporting, including OpenSearch, PyPI mistralai@2.4.6, PyPI guardrails-ai@0.10.1, and additional Squawk-related npm packages.

The broader campaign can be summarized like this:

Mini Shai-Hulud
  + credential stealing
  + package maintainer enumeration
  + cross-ecosystem infection across npm and PyPI
  + persistence in Claude Code, VS Code, and GitHub Actions

The attacker did not only steal credentials. The malware also enumerated packages that a maintainer could publish to, then republished infected versions. A compromise in one developer machine or CI/CD environment could therefore spread into another package ecosystem.

Worm behavior

The post-install flow looks roughly like this:

Compromised package install
  -> install of an infected package

router_init.js / transformers.pyz
  -> malicious payload execution

credential theft
  -> credential collection
  - GitHub token
  - npm token
  - cloud credentials
  - SSH keys
  - CI secrets

exfiltration
  -> data exfiltration
  - filev2.getsession.org
  - seed1/2/3.getsession.org
  - GitHub GraphQL dead drop

self-propagation
  -> spreading to more packages and repositories
  - enumerate maintainer packages
  - publish infected versions
  - inject workflows / persistence hooks

Stolen data was sent to Session/Oxen-related infrastructure such as filev2.getsession.org and seed1.getsession.org. The Hacker News describes the use of filev2.getsession.org and Session Protocol infrastructure as an attempt to evade detection, since those domains may be less likely to be blocked in enterprise environments.

There was also a fallback path that used stolen GitHub tokens to commit encrypted data to attacker-controlled repositories through the GitHub GraphQL API. This is essentially a dead drop: if the malware cannot send data directly to an external server, it can temporarily place the data in a GitHub repository for later retrieval. The commit author claude@users.noreply.github.com is one IOC to look for in that path.

Persistence and lateral movement

The concerning part is not only the credential theft that happens at install time. The reported persistence and lateral movement surface is broad.

StepSecurity and Socket describe artifacts such as:

.claude/settings.json
.claude/router_runtime.js
.claude/setup.mjs
.vscode/tasks.json
.vscode/setup.mjs
~/Library/LaunchAgents/com.user.gh-token-monitor.plist
~/.config/systemd/user/gh-token-monitor.service
.github/workflows/codeql_analysis.yml

If hooks are installed into Claude Code or VS Code, the stealer can run again when the IDE starts. The gh-token-monitor service is used to monitor and retransmit GitHub tokens.

There are also reports of injected GitHub Actions workflows that serialize repository secrets with toJSON(secrets) and send them to api.masscan.cloud.

On the CI/CD side, StepSecurity reported an especially important behavior. On Linux GitHub Actions runners, the malicious payload looked for the Runner.Worker process and read /proc/<pid>/mem to extract workflow secrets, including masked secrets. That means even secrets not explicitly referenced in the workflow YAML may be at risk if they are present in the runner process memory.

PyPI was also affected

This was not only an npm incident.

Socket highlights PyPI guardrails-ai@0.10.1 because malicious code could run on import. On Linux, it downloaded a Python artifact from git-tanstack.com/transformers.pyz, wrote it to /tmp/transformers.pyz, and executed it with python3. Socket notes that this behavior was not present in the previous guardrails-ai@0.10.0 release.

The Hacker News, citing Microsoft's analysis on X, also discusses mistralai@2.4.6, including behavior that fetched a credential stealer from a remote server, avoided Russian-language environments, and included destructive branching for environments that appeared to be in certain regions.

Watching npm lifecycle scripts is not enough. Python imports, CI installs, developer machines, and IDE hooks all matter here.

SLSA provenance was not enough

One of the most important details is that the malicious packages were published through legitimate GitHub Actions OIDC trusted publishing and had valid SLSA provenance.

Provenance tells you which pipeline produced an artifact. It does not prove that the pipeline was not contaminated by attacker-controlled code.

In this attack, the trusted pipeline itself became the attacker's publish path. A provenance badge or Sigstore attestation alone is not enough to conclude that the artifact is safe.

Initial response

If a developer machine or runner may have installed an affected version, reverting the lockfile is not enough. At the same time, this article should not be treated as a full incident-response runbook. It is safer to follow the official advisory and vendor analyses.

The TanStack GitHub Advisory recommends treating affected developer machines and CI environments as compromised, rotating credentials that were accessible from the install process, checking cloud audit logs, and auditing CI pipelines.

Start with these references:

TanStack GitHub Advisory: affected versions, patched versions, workaround, IOCs
StepSecurity analysis: GitHub Actions, OIDC, SLSA provenance, secret exfiltration
Socket analysis: additional affected packages, PyPI, persistence artifacts, detection notes

In practice, the areas to check include:

isolation of affected machines and runners
rotation of GitHub PATs, npm tokens, cloud credentials, Vault tokens, Kubernetes tokens, and SSH keys
rotation of GitHub Actions secrets and environment secrets
npm publish logs and unexpected changes in GitHub repositories
persistence artifacts under .claude/, .vscode/, LaunchAgent, and systemd user services
egress to filev2.getsession.org, seed*.getsession.org, and api.masscan.cloud

StepSecurity also warns about npm tokens with the description IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner. Because that may indicate destructive behavior, token revocation should be handled from a clean machine and according to the organization's incident-response process, not casually from a potentially infected host.

Prevention lessons

The lesson is not just "be careful with pull_request_target."

do not share cache between untrusted PR workflows and release pipelines
do not checkout and execute untrusted code in pull_request_target
grant id-token: write only to the publish job
explicitly set permissions: id-token: none elsewhere
separate release workflows from normal test workflows
pin third-party actions by commit SHA instead of tags
avoid leaving secrets on self-hosted or long-lived runners
enforce lockfiles and frozen installs
add a minimum release age for dependency updates

With pnpm, minimumReleaseAge can be set in pnpm-workspace.yaml. For example, a 7-day delay is 10080 minutes. In pnpm 11, minimumReleaseAgeStrict can also be set when you want stricter behavior.

minimumReleaseAge: 10080
minimumReleaseAgeStrict: true

This is not a complete defense. It will not magically clean a malicious version already in your lockfile, and it will not protect you if you explicitly install a malicious version. But it can reduce the chance of immediately pulling a newly published malicious release.

Conclusion

If you explain the TanStack incident only as a pull_request_target mistake, it sounds smaller than it was.

The broader picture is a self-propagating worm that crossed CI/CD, caches, OIDC, npm trusted publishing, IDE hooks, GitHub Actions secrets, and PyPI. The attacker did not merely compromise packages. They used developer and CI environments as stepping stones to reach the next maintainer and the next package.

The right mental model is not just "dependency package compromise." It is developer environment and CI/CD compromise.

推荐订阅源

DEV Community