Mini Shai-Hulud: an npm and PyPI worm (2026)

In autumn 2025 the npm ecosystem saw its first self-replicating worm — Shai-Hulud. In May 2026 it returned in a new guise, dubbed by researchers “Mini Shai-Hulud,” and did something not seen at this scale before: it infected packages in npm and PyPI simultaneously, in a single coordinated operation. Victims included popular TanStack libraries and components tied to Mistral AI and UiPath — more than 160 packages in total. It’s further proof that the software supply chain is now one of the most effective attack vectors.

How the attack worked

The mechanics combined a hijacked build pipeline with classic secret theft, in an automated loop:

1. Entry via CI/CD. According to analyses (including Orca Security and Palo Alto Unit 42), the foothold was the GitHub Actions pipeline of the TanStack project. Attackers exploited a chain of misconfigurations in Actions to hijack the build-and-publish process.
2. Lightning-fast publishing. Once the pipeline was taken over, malicious artifacts began landing in the registry at machine speed — within minutes, dozens of infected packages from the @tanstack/* family were published.
3. Secret theft. The payload scanned the environment for npm tokens, cloud credentials, keys and pipeline secrets, then exfiltrated them.
4. Self-replication. With stolen publishing rights, the worm automatically poisoned further packages maintained by its victims — hence “worm,” not a single malicious package.

Two traits set this wave apart. First, the simultaneous hit on npm and PyPI — for the first time a single operation poisoned both major registries, showing the actors now think “cross-ecosystem.” Second, in some variants the payload included a destructive, persistent component capable of wiping developers’ home directories — so we’ve moved from theft toward sabotage.

Why it’s so dangerous

The attack strikes the same foundation as its predecessor: trust in dependencies and in automation. A typical app pulls in hundreds, indirectly thousands, of packages — nobody reads their code on every update. When a malicious version slips into the build, it runs where privileges are broadest: in CI/CD. And a pipeline usually holds cloud tokens, deployment keys and registry access — potentially the keys to the whole environment.

The novelty of 2026 is the scale of automation and the targeting of the vendor’s toolchain: what gets hijacked is not so much an individual author’s account as their publishing pipeline. It’s the same family of threats we covered in the March TeamPCP wave against CI/CD — here taken to the form of a self-replicating worm operating on two registries at once.

How to defend: practical steps

You can’t protect against every future registry infection, but you can drastically limit the impact.

Harden GitHub Actions. That was the entry vector. Pin actions to specific commit SHAs (not moving tags), reduce the default GITHUB_TOKEN permissions to a minimum, separate the publish workflow from ordinary CI and protect it with approvals. Wherever possible, issue short-lived tokens via OIDC instead of storing long-lived secrets.

Pin versions and use a lockfile. Installing from locked versions (npm ci instead of npm install, a lockfile in the repo; the Python equivalents) means a fresh malicious version won’t jump in automatically. Consider delaying adoption of new releases by a few days — many malicious packages are detected and removed within that window.

Restrict install scripts. --ignore-scripts where feasible blocks the most common vector for running malicious code during installation. In CI this is especially important.

Least privilege in the pipeline. A build shouldn’t have tokens with broader scope than the specific job requires. Separate tokens for build and deploy, with no production access from the dependency-install stage.

Provenance and SBOM. Verifying artifact provenance (Sigstore and SLSA) and maintaining a dependency inventory let you answer “does this affect us?” faster when the next wave is announced.

Rotate secrets after an incident. If you might have been in the exposure window, assume tokens leaked and rotate them. Secret theft makes a mere package “fix” insufficient.

Frequently asked questions (FAQ)

We use npm or PyPI — were we at risk? Potentially yes, if during the attack window you installed fresh versions of the infected packages (or their dependencies) without locked versions, or with scripts running in CI. Check whether any package from the IOC list reached your builds and whether pipeline tokens leaked.

How does “Mini Shai-Hulud” differ from the 2025 original? Scale and reach. The original circulated on npm; the 2026 version attacked npm and PyPI at once, leaned harder on hijacking the publishing pipeline, and in some variants added a destructive, data-wiping component.

How do we check whether our tokens leaked? Review the registries’ publish logs and the activity of GitHub/cloud tokens from the exposure period, look for unauthorised package publishes and unusual key usage. When in doubt — rotate everything that could have been within reach of the CI payload.

How do we test our pipeline’s resilience? A security audit covering CI/CD checks token scopes, GitHub Actions configuration, build-environment isolation and the risk of malicious dependencies — exactly the conditions that decided this worm’s scale.

Summary

Mini Shai-Hulud confirms the direction its predecessor signalled: automated, self-replicating supply-chain attacks that spread faster than you can react by hand — and now across the boundary of a single registry. Defence isn’t about reading the code of every dependency; it’s about limiting impact: a hardened pipeline, locked versions, least privilege and fast secret rotation. If you build software, check your pipeline before the next worm does.

---

Sources and further reading: Orca Security, Palo Alto Unit 42, GitHub Security.