Any development environment that installed or imported one of the 172 compromised npm or PyPI packages released since May 11 should be considered potentially compromised. On affected developer workstations, the worm extracts credentials from over 100 file paths, including AWS keys, SSH private keys, npm tokens, GitHub PATs, HashiCorp Vault tokens, Kubernetes service accounts, Docker configurations, shell history, and cryptocurrency wallets. For the first time in a TeamPCP campaign, it also targets password managers such as 1Password and Bitwarden, according to SecurityWeek.
The worm also captures Claude and Kiro AI agent configurations, including MCP server authentication tokens for all external services an agent connects with. It does not leave even when the package is removed.
The worm establishes persistence in Claude Code (.claude/settings.json) and VS Code (.vscode/tasks.json with runOn: folderOpen) to re-execute whenever a project is opened, alongside a system daemon (macOS LaunchAgent / Linux systemd) that endures reboots. These reside in the project tree, not in node_modules, and removing the package does not eliminate them. On CI runners, the worm directly reads runner process memory via /proc/pid/mem to retrieve secrets, including masked ones, on Linux-based runners. If tokens are revoked before isolating the machine, Wizâs analysis reveals a destructive daemon erases your home directory.
Between 19:20 and 19:26 UTC on May 11, the Mini Shai-Hulud worm released 84 malicious versions across 42 @tanstack/* npm packages. Within 48 hours, the campaign grew to 172 packages spanning 403 malicious versions across npm and PyPI, as tracked by Mend. @tanstack/react-router alone sees 12.7 million weekly downloads. CVE-2026-45321, CVSS 9.6. OX Security reported that 518 million cumulative downloads were affected. All malicious versions had a valid SLSA Build Level 3 provenance attestation. The provenance was legitimate, but the packages were tampered with.
âTanStack had the right setup on paper: OIDC trusted publishing, signed provenance, 2FA on every maintainer account. The attack worked anyway,â Peyton Kennedy, a senior security researcher at Endor Labs, explained to VentureBeat in an exclusive interview. âWhat the orphaned commit technique shows is that OIDC scope is the actual control that matters here, not provenance, not 2FA. If your publish pipeline trusts the entire repository rather than a specific workflow on a specific branch, a commit with no parent history and no branch association is enough to get a valid publish token. Thatâs a one-line configuration fix.â
Three vulnerabilities combined into one provenance-attested worm
TanStackâs postmortem describes the attack chain. On May 10, the attacker forked TanStack/router under the name zblgg/configuration, a name chosen to avoid fork-list searches according to Snykâs analysis. A pull request triggered a pull_request_target workflow that checked out fork code and ran a build, allowing the attacker code execution on TanStackâs runner. The attacker then poisoned the GitHub Actions cache. When a legitimate maintainer merged to main, the release workflow restored the poisoned cache. Attacker binaries accessed /proc/pid/mem, extracted the OIDC token, and sent it directly to registry.npmjs.org. Tests failed, but 84 signed packages still reached the registry.
âEach vulnerability bridges the trust boundary the others assumed,â the postmortem states. Techniques from the March 2025 tj-actions/changed-files compromise were reused in a new context.
The worm spread from npm to PyPI within hours
Microsoft Threat Intelligence verified that the mistralai PyPI package v2.4.6 executes on import, not on installation, downloading a payload disguised as Hugging Face Transformers. npm mitigations (lockfile enforcement, âignore-scripts) do not account for Python import-time execution.
Mistral AI released a security advisory detailing the impact. Compromised npm packages were available between May 11 at 22:45 UTC and May 12 at 01:53 UTC, approximately three hours. The PyPI release mistralai==2.4.6 is quarantined. Mistral confirmed an affected developer device was involved, but no Mistral infrastructure was compromised. SafeDep verified Mistral never released v2.4.6; no commits occurred on May 11, and no tag exists.
Wiz chronicled the full blast radius: 65 UiPath packages, Mistral AI SDKs, OpenSearch, Guardrails AI, and 20 Squawk packages. StepSecurity attributes the campaign to TeamPCP, citing toolchain similarities with previous Shai-Hulud waves and the Bitwarden CLI/Trivy compromises. The worm operates under Bun instead of Node.js to avoid Node.js security monitoring.
The attacker considered AI coding agents as part of the trusted execution environment
Socketâs technical analysis of the 2.3 MB router_init.js payload identifies ten credential-collection classes running in parallel. The worm installs persistence into .claude/ and .vscode/ directories, hooking into Claude Codeâs SessionStart configuration and VS Codeâs folder-open task runner. StepSecurityâs deobfuscation confirmed the worm also collects Claude and Kiro MCP server configurations (~/.claude.json, ~/.claude/mcp.json, ~/.kiro/settings/mcp.json), which store API keys and authentication tokens for external services. This marks an early but confirmed case of supply-chain malware targeting AI agent configurations as valuable credential targets. The npm token description set by the worm reads: âIfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.â This is not an idle threat.
âWhat stood out to me about this payload is where it planted itself after running,â Kennedy told VentureBeat. âIt wrote persistence hooks into Claude Codeâs SessionStart config and VS Codeâs folder-open task runner, ensuring it would re-execute every time a developer opened a project, even after the npm package was removed. The attacker treated the AI coding agent as part of the trusted execution environment, which it is. These tools read your repo, run shell commands, and have access to the same secrets a developer does. Securing a development environment now means thinking about the agents, not just the packages.â
CI/CD Trust-Chain Audit Grid
Six gaps the Mini Shai-Hulud exploited. What your CI/CD does today. The control that closes each one.
|
Audit question |
What your CI/CD does today |
The gap |
|
1. Pin OIDC trusted publishing to a specific workflow file on a specific protected branch. Constrain id-token: write to only the publish job. Ensure that job runs from a clean workspace with no restored untrusted cache |
Most organizations grant OIDC trust at the repository level. Any workflow run in the repo can request a publish token. id-token: write is often set at the workflow level, not scoped to the publish job. |
The worm achieved code execution inside the legitimate release workflow through cache poisoning, then extracted the OIDC token from runner process memory. Branch/workflow pinning alone would not have stopped this attack because the malicious code was already running inside the pinned workflow. The complete fix requires pinning PLUS constraining id-token: write to only the publish job PLUS ensuring that job uses a clean, unshared cache. |
|
2. Treat SLSA provenance as necessary but not sufficient. Add behavioral analysis at install time |
Teams treat a valid Sigstore provenance badge as proof a package is safe. npm audit signatures passes. The badge is green. Procurement and compliance workflows accept provenance as a gate. |
All 84 malicious TanStack versions carry valid SLSA Build Level 3 provenance attestations. First widely reported npm worm with validly-attested packages. Provenance attests where a package was built, not whether the build was authorized. Socketâs AI scanner flagged all 84 artifacts within six minutes of publication. Provenance flagged zero. |
|
3. Isolate GitHub Actions cache per trust boundary. Invalidate caches after suspicious PRs. Never check out and execute fork code in pull_request_target workflows |
Fork-triggered workflows and release workflows share the same cache namespace. Closing or reverting a malicious PR is treated as restoring clean state. pull_request_target is widely used for benchmarking and bundle-size analysis with fork PR checkout. |
Attacker poisoned pnpm store via fork-triggered pull_request_target that checked out and executed fork code on the base runner. Cache survived PR closure. The next legitimate release workflow restored the poisoned cache on merge. actions/cache@v5 uses a runner-internal token for cache saves, not the workflowâs GITHUB_TOKEN, so permissions: contents: read does not prevent mutation. Kennedy: âBranch protection rules donât apply to commits that arenât on any branch, so that whole layer of hardening didnât help.â |
|
4. Audit optionalDependencies in lockfiles and dependency graphs. Block github: refs pointing to non-release commits |
Static analysis and lockfile enforcement focus on dependencies and devDependencies. optionalDependencies with github: commit refs are not flagged by most tools. |
The worm injected optionalDependencies pointing to a github: orphan commit in the attackerâs fork. When npm resolves a github: dependency, it clones the referenced commit and runs lifecycle hooks (including prepare) automatically. The payload executed before the main packageâs own install step completed. SafeDep confirmed Mistral never released v2.4.6; no commits landed and no tag exists. |
|
5. Audit Python dependency imports separately from npm controls. Cover AI/ML pipelines consuming guardrails-ai, mistralai, or any compromised PyPI package |
npm mitigations (lockfile enforcement, âignore-scripts) are applied to the JavaScript stack. Python packages are assumed safe if pip install completes. AI/ML CI pipelines are treated as internal testing infrastructure, not as supply-chain attack targets. |
Microsoft Threat Intelligence confirmed mistralai PyPI v2.4.6 executes on import, not install. Injected code in __init__.py downloads a payload disguised as Hugging Face Transformers. âignore-scripts is irrelevant for Python import-time execution. guardrails-ai@0.10.1 also executes on import. Any agentic repo with GitHub Actions id-token: write is exposed to the same OIDC extraction technique. LLM API keys, vector DB credentials, and external service tokens all in the blast radius. |
|
6. Isolate and image affected machines before revoking stolen tokens. Do not revoke npm tokens until the host is forensically preserved |
Standard incident response: revoke compromised tokens first, then investigate. npm token list and immediate revocation is the instinctive first step. |
The worm installs a persistent daemon (macOS LaunchAgent / Linux systemd) that polls GitHub every 60 seconds. On detecting token revocation (40X error), it triggers rm -rf ~/, wiping the home directory. The npm token description reads: âIfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.â Microsoft reported geofenced destructive behavior: a 1-in-6 chance of rm -rf / on systems appearing to be in Israel or Iran. Kennedy: âEven after the package is gone, the payload may still be sitting in .claude/ with a SessionStart hook pointing at it. rm -rf node_modules doesnât remove it.â |
Sources: TanStack postmortem, StepSecurity, Socket, Snyk, Wiz, Microsoft Threat Intelligence, Mend, Endor Labs. May 12, 2026.
Security director action plan
-
Today: âThe fastest check is find . -name ârouter_init.jsâ -size +1M and grep -r â79ac49eedf774dd4b0cfa308722bc463cfe5885câ package-lock.json,â Kennedy said. If either returns a hit, isolate and image the machine immediately. Do not revoke tokens until the host is forensically preserved. The wormâs destructive daemon triggers on revocation. Once the machine is isolated, rotate credentials in this order: npm tokens first, then GitHub PATs, then cloud keys. Hunt for .claude/settings.json and .vscode/tasks.json persistence artifacts across every project that was open on the affected machine.
-
This week: Rotate every credential accessible from affected hosts: npm tokens, GitHub PATs, AWS keys, Vault tokens, K8s service accounts, SSH keys. Check your packages for unexpected versions after May 11 with commits by claude@users.noreply.github.com. Block filev2.getsession[.]org and git-tanstack[.]com.
-
This month: Audit every GitHub Actions workflow against the six gaps above. Pin OIDC publishing to specific workflows on protected branches. Isolate cache keys per trust boundary. Set npm config set min-release-age=7d. For AI/ML teams: check guardrails-ai and mistralai against compromised versions, audit CI pipelines for id-token: write exposure, and rotate every LLM API key and vector DB credential accessible from CI.
-
This quarter (board-level): Fund behavioral analysis at the package registry layer. Provenance verification alone is no longer a sufficient procurement criterion for supply-chain security tooling. Require CI/CD security audits as part of vendor risk assessments for any tool with publish access to your registries. Establish a policy that no workflow with id-token: write runs from a shared cache. Treat AI coding agent configurations (.claude/, .kiro/, .vscode/) as credential stores subject to the same access controls as cloud key vaults.
The worm is evolving. Defenders must adapt, too
This marks the fifth Shai-Hulud wave in eight months. Four SAP packages escalated to 84 TanStack packages in two weeks. intercom-client@7.0.4 succumbed 29 hours later, confirming active spread through stolen CI/CD infrastructure. Late on May 12, malware research group vx-underground reported that the fully weaponized Shai-Hulud worm code has been open-sourced. If verified, this means the attack is no longer confined to TeamPCP. Any threat actor can now use the same cache-poisoning, OIDC-extraction, and provenance-attested publishing chain against any npm or PyPI package with a vulnerable CI/CD setup.
âWeâve been monitoring this campaign family since September 2025,â Kennedy said. âEach wave has targeted a higher-download package and introduced a more technically intriguing access vector. The orphaned commit technique here is genuinely novel. Branch protection rules donât apply to commits not associated with any branch. The supply chain security space has focused heavily on provenance and trusted publishing over the last two years. This attack bypassed both controls because the gap wasnât in signing. It was in scope.â
Provenance indicates where a package was built. It does not confirm whether the build was authorized. This audit aims to address that gap.
