Shai-Hulud Worm Compromises 170+ npm, PyPI Packages in May 2026

In May 2026, the Mini Shai-Hulud campaign resurfaced and compromised over 170 npm and PyPI packages, with reports also citing 373 malicious version entries across 169 npm packages and 2 PyPI packages in a sophisticated supply chain attack. The campaign, dubbed "Mini Shai-Hulud," demonstrated rapid cross-registry propagation and exposed critical gaps in security signals from trusted build systems.

According to industry reports, the attack began in May 2026, with security teams detecting a coordinated assault on both registries. Initial reports from Microsoft Security Research identified a significant number of compromised npm packages and PyPI packages. According to industry reports, the malicious versions reached substantial download numbers within days, impacting major projects like TanStack, Mistral AI, UiPath, and OpenSearch.

How the worm spread

The Shai-Hulud worm propagates by stealing credentials like npm and GitHub tokens from compromised developer machines and CI/CD runners. It then uses automated scripts to autonomously publish new infected packages, creating a rapid, self-sustaining infection cycle that spreads across multiple software ecosystems without further attacker intervention.

According to industry reports, the initial breach vector was a compromised GitHub Actions pipeline belonging to TanStack, where a significant number of packages were poisoned rapidly. From there, the worm leveraged package installation scripts to replicate itself across developer machines and CI systems. Credential theft was central to its success; the malware harvested npm tokens, GitHub tokens, and browser cookies to publish more malicious packages. This expanded the attack surface by exfiltrating stolen cloud keys and other developer secrets to public repositories.

Why provenance was ineffective

This attack marked a significant escalation by successfully forging valid SLSA Build Level 3 attestations. Attackers abused stolen OIDC tokens from a compromised build pipeline to generate cryptographically valid Sigstore bundles for their malicious packages. Because these signatures appeared legitimate, automated defenses that rely solely on provenance checks were bypassed.

This incident proves that provenance alone is not a guarantee of safety. While it can verify who built an artifact, it cannot prove the code is benign if the build environment itself is compromised. True supply chain security requires pairing provenance verification with strict behavioral and policy enforcement.

Defensive takeaways

1. Treat Package Installation as Code Execution: Recognize that installing any package, especially in developer environments and CI/CD systems, is a potential vector for secret harvesting and lateral movement.
2. Harden Maintainer Identity: Mitigate account takeover risk by enforcing phishing-resistant MFA, using short-lived access tokens, and implementing strict branch protection rules on code repositories.
3. Verify Provenance Against Policy: Do not treat a valid signature as a guarantee of safety. Consumers must validate provenance details like the repository, workflow, and builder identity against a pre-approved policy before trusting an artifact.
4. Monitor Across Ecosystems: Since this was a coordinated cross-ecosystem campaign, security teams should monitor both npm and PyPI feeds concurrently to detect related threats.
5. Audit for Downstream Propagation: If a compromised dependency is detected, assume downstream assets are also compromised. Immediately trigger rebuilds and rotate all credentials associated with any workflow that ingested the malicious package.

The Shai-Hulud worm demonstrates that comprehensive supply chain defense demands a multi-layered strategy. Organizations must extend security visibility from developer environments through build pipelines and into production, combining strong identity controls, policy-driven provenance verification, and continuous monitoring to defend against next-generation threats.

---

What exactly is the Shai-Hulud worm and how fast did it spread?

Shai-Hulud is a self-replicating supply-chain worm open-sourced by the financially motivated group TeamPCP.
According to industry reports, the first wave hijacked npm maintainer tokens and published a significant number of malicious versions rapidly; the same token pushed many malicious releases across numerous distinct packages at unprecedented speed for public-registry abuse.
The malware immediately harvests npm tokens, GitHub tokens and cloud keys, then re-uses each stolen credential to infect every package the account can reach, creating secondary and tertiary infection waves without human interaction.

How did the attackers forge "signed" packages that looked legitimate?

TeamPCP compromised GitHub Actions OIDC tokens issued to the TanStack organisation and fed those tokens into the official Sigstack / Sigstore stack.
Because the OIDC subject matched a repository that already published Level-3 SLSA provenance, the resulting malicious artifacts carried perfectly valid, cryptographically signed attestations.
Consumers who relied on "signed = safe" were infected even though the provenance never warned that the underlying code had changed.

Which big-name projects were hit and what damage was done?

According to industry reports, major projects including TanStack, Mistral AI, UiPath and OpenSearch were directly impacted, with substantial download numbers of the poisoned versions within the first days.
Payloads stole AWS, GCP and Azure keys, back-doored Claude Code and Codex sessions, and in one PyPI package (durabletask) dropped a disk wiper that activated when the host locale equalled Israel or Iran.

What makes this campaign different from earlier supply-chain attacks?

• Cross-ecosystem: the same stolen token published simultaneously to npm and PyPI, something no previous operation had achieved in a single coordinated push.
• Provenance abuse: it proved that valid SLSA Build Level-3 provenance can still deliver unsafe code if the pipeline itself is hijacked.
• Worm behaviour: instead of one-shot poisoning, the code auto-publishes using each fresh credential, creating exponential growth that does not need the original attacker online.

How can teams defend against similar provenance-forgery or AI-assistant backdoors?

1. Verify, don't trust provenance
   Reject an artifact unless its attestation matches exact repository, workflow, branch and builder identity you pre-approved.
2. Pin and isolate
   Lock dependencies to hash-pinned versions, run builds on ephemeral, hosted runners, and keep signing keys outside the build container.
3. Rotate and scope tokens
   Issue short-lived OIDC tokens with the narrowest permissions: block; rotate every secret immediately if any job installs a package during the exposure window.
4. Audit AI tooling
   Search .vscode/, .claude/ and shell hooks for persistence artifacts; never let an assistant hold publish tokens or cloud credentials.
5. Cross-registry monitoring
   Watch both npm and PyPI alerts together - defenders who silo the two ecosystems missed a significant portion of Mini Shai-Hulud samples in the first day.