A new Mini Shai-Hulud wave turned a trusted release workflow into the delivery path for malicious npm packages. TanStack says that on May 11, 2026, an attacker published 84 malicious versions across 42 @tanstack/* packages between 19:20 and 19:26 UTC by chaining a pull_request_target issue, GitHub Actions cache poisoning, and extraction of an OIDC token from runner memory [1].
The important part is not only the package count. TanStack says no npm tokens were stolen and the normal npm publish workflow was not directly compromised. The bad releases were still authenticated through the project’s trusted-publisher path after attacker-controlled code ran inside the workflow. That makes this a sharper version of the developer supply-chain problem we covered in the Checkmarx Jenkins plugin compromise: the attacker does not need every downstream victim, only one trusted automation lane.
A similar registry-trust problem later appeared in RubyGems, where new account signups were paused after reports of hundreds of malicious packages.
Why signed packages still need incident response
Trusted publishing and provenance are useful controls, but this incident shows their boundary. Socket notes that an attacker who can execute inside GitHub Actions can generate valid Sigstore attestations for malicious packages, so a provenance badge should not be treated as a standalone safety signal [2]. Aikido’s malware team tracked the broader wave at 373 malicious package-version entries across 169 npm package names, with the same basic goal: steal credentials from developer machines and CI/CD runners, then use those credentials to reach more packages [3].
That changes the response order. If a project installed affected packages during the window, checking only today’s lockfile is not enough. Teams should inspect package-manager caches, CI logs, build timestamps, runner workspaces, and developer machines that performed installs. Snyk reports that affected TanStack tarballs included a large obfuscated router_init.js payload and an injected optional dependency, both useful clues when searching old artifacts or retained CI workspaces [4].
The clean-up sequence should be treated like a credential-theft incident, not just dependency hygiene. First isolate build runners and developer hosts that installed suspect versions, clear poisoned caches, remove affected package artifacts, and pause workflows that can publish or mint OIDC tokens. Only then rotate reachable npm, GitHub, SSH, cloud, Kubernetes, and Vault secrets. Rotating first can leave new secrets exposed if the runner or workstation is still executing the malicious install path.
For maintainers, the audit should focus on the workflow edges attackers abused: pull_request_target jobs that run attacker-influenced code, cache keys shared between untrusted PR runs and release jobs, and broad id-token: write permissions. OIDC should be limited to the single publish job that needs it, with repository or environment rules around release paths. The same logic applies to PyPI package abuse and fake developer tooling such as the fake OpenAI Hugging Face infostealer campaign: malware can arrive through channels that look legitimate until the build or install behavior is inspected.
TanStack has deprecated the affected versions and engaged npm security to pull malicious tarballs, but the wider Mini Shai-Hulud campaign was still being tracked across npm and PyPI as of May 12. Any organization that builds JavaScript or Python software should treat this as a prompt to review recent installs, not as a TanStack-only event.
Update: the campaign continued in a later Shai-Hulud wave against AntV npm packages, with researchers also tracking related PyPI exposure.
A later downstream case showed the operational risk after token rotation: Grafana said one missed workflow token let attackers copy private repositories.
A newer Composer ecosystem case shows the same supply-chain lesson from a different angle: Laravel-Lang package tags were rewritten to run a credential stealer through Composer autoload.
References
- TanStack, “Postmortem: TanStack npm supply-chain compromise,” May 11, 2026. Postmortem
- Socket Research Team, “TanStack npm Packages Compromised in Ongoing Mini Shai-Hulud Supply-Chain Attack,” published May 11, 2026, updated May 12, 2026. Analysis
- Aikido Security, “Mini Shai-Hulud Is Back: npm Worm Hits over 160 Packages, including Mistral and Tanstack,” May 12, 2026. Report
- Snyk, “TanStack npm Packages Hit by Mini Shai-Hulud,” May 11, 2026. Analysis
Related: Another npm ecosystem incident now targets the long-running node-ipc package with a credential stealer, showing the same developer-secret risk through a different dependency route.
