Critical Advisory: The "Mini Shai-Hulud" Supply Chain Attack

If your team uses @tanstack/*, Mistral AI, UiPath, OpenSearch, Guardrails AI, or related npm/PyPI packages, review your exposure immediately.

As of May 13, 2026, public advisories confirm that a supply-chain campaign known as Mini Shai-Hulud affected major npm and PyPI ecosystems. The TanStack incident is tracked as GHSA-g7cv-rxg3-hmpx / CVE-2026-45321.

What Happened

On May 11, 2026, between 19:20 and 19:26 UTC, attackers published 84 malicious versions across 42 @tanstack/* npm packages.

This was not a typical stolen-token package takeover. According to the TanStack postmortem and GitHub advisory, the attacker chained:

• A pull_request_target “Pwn Request” workflow weakness
• GitHub Actions cache poisoning across the fork-to-base trust boundary
• Runtime extraction of an OIDC token from GitHub Actions runner memory

The malicious publishes were authenticated through TanStack’s legitimate GitHub Actions OIDC trusted-publisher binding. The publish workflow itself was not directly modified, and TanStack reports no npm tokens were stolen in the initial TanStack compromise.

Why This Is Different: The Provenance Problem

Security researchers report that some malicious packages in this campaign carried valid npm/Sigstore provenance attestations, including SLSA Build Level 3-style provenance.

That matters because the provenance was not forged. The attacker abused the legitimate build environment and trusted-publisher path.

The lesson: cryptographic provenance can prove where a package was built and published from, but it does not prove that the build environment or the code being built was safe.

How the Attack Worked

GitHub Actions cache poisoning

The attacker abused a pull_request_target workflow and caused malicious content to be written into the GitHub Actions cache used by later trusted workflows.

OIDC hijack during a legitimate release

When maintainers later triggered a real release workflow, the runner restored the poisoned cache. The malware then extracted an OIDC token from runner memory.

Trusted publishing abuse

The attacker used the OIDC token to publish malicious packages through the legitimate npm trusted-publisher path.

Worm-like propagation

The payload attempted to steal developer and CI/CD credentials, then use those credentials to publish further compromised packages.

Researchers have linked the broader campaign to TeamPCP, including affected packages associated with Mistral AI, UiPath, OpenSearch, Guardrails AI, Squawk, and others.

Important: Handle Token Revocation Carefully

Some analyses report a persistence/wiper component called gh-token-monitor. It may monitor GitHub token status and trigger destructive behavior if a stolen token is revoked.

Do not interpret this as “never revoke tokens.” Instead:

• Immediately isolate suspected hosts or CI runners.
• Check for and remove gh-token-monitor persistence first.
• Then revoke and rotate exposed credentials.

Look for persistence artifacts such as:

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

After containment, rotate all reachable credentials, including npm tokens, GitHub PATs, cloud credentials, SSH keys, Kubernetes service account tokens, Vault tokens, and CI/CD secrets.

Steps to Protect Your Organization

Audit affected packages and lockfiles

Check for affected @tanstack/* versions, @tanstack/setup, router_init.js, and suspicious package versions published around May 11, 2026.

Review pull_request_target workflows

Any workflow that runs fork-controlled code, restores or writes cache, or has elevated permissions should be treated as high risk.

Harden trusted publishing

For npm trusted publishing, pin publishers to the specific organization, repository, and workflow file. Use GitHub environments and environment protection rules to restrict publish jobs further.

Restrict OIDC permissions

Set id-token: none by default. Grant id-token: write only to the exact job that performs publishing.

Avoid caches in release workflows

Release jobs should be as deterministic and isolated as possible. Do not let untrusted PR workflows write cache entries that release workflows later consume.

Use dependency cooldowns

Configure package managers to avoid newly published packages by default:

• npm: min-release-age=7
• pnpm: minimumReleaseAge: 10080
• uv: exclude-newer = "1 week"

Do not trust provenance alone

Provenance is still useful, but it must be combined with workflow isolation, cache hygiene, dependency review, and runtime monitoring.

References

Start with:

• GitHub Advisory: GHSA-g7cv-rxg3-hmpx
• NVD: CVE-2026-45321
• TanStack Postmortem
• StepSecurity Analysis

Supply-chain security is no longer only about who wrote the code. It is also about whether the environment that built and published the code was trustworthy.