The Worm That Writes Itself: How 'Shai-Hulud' Is Poisoning the Open-Source Code Everyone Uses
Shai-Hulud, a self-spreading worm, has poisoned hundreds of npm packages, stealing developer secrets and cloning itself automatically. Inside the attack.
Picture a saboteur who, the moment he breaks into one factory, automatically forges the keys to a hundred more, slips copies of himself onto every delivery truck leaving the loading bay, and does it all again at the next factory — no human directing any of it. That is, in software form, the Shai-Hulud worm: a piece of malware that copies and spreads itself through the open-source code that almost every modern app is built from. In 2026 it became one of the clearest warnings yet that the software supply chain is now a battlefield.
- What: a self-spreading worm in npm (the main JavaScript package registry) and beyond.
- How it grows: it steals developers’ secret tokens, then uses them to poison more packages — automatically, with no attacker at the keyboard.
- Scale (May 2026): 300+ malicious package versions published across 323 packages in a single 22-minute burst.
- Why you should care: the apps you use are assembled from thousands of these packages. Poison the parts, and you poison everything built from them.
What “open source” really means here
When a developer builds an app, they don’t write every line from scratch. They pull in free, ready-made building blocks — “packages” — from public registries like npm, the dominant registry for JavaScript. A single app can depend on hundreds or thousands of them, each written and maintained by strangers, each automatically pulling in others. That shared foundation is what makes modern software fast to build — and what makes a self-replicating worm so dangerous. Compromise one widely-used package and you are, in effect, inside everything downstream.
A worm returns, and evolves
The original Shai-Hulud worm tore through npm in 2025. In April 2026 a new variant, Mini Shai-Hulud, surfaced — first probing the SAP developer ecosystem, then exploding into a far larger campaign that had compromised more than 160 packages by May. Unlike a one-off poisoned package that someone has to plant by hand, this strain was built to keep going on its own.
How it spreads with no human at the keyboard
The worm’s genius — and its menace — is that it weaponises the trusted machinery developers rely on every day:
- Once it infects a package, it hunts for secrets and access tokens on developer machines and inside automated build pipelines.
- It uses those stolen tokens to publish malicious new versions of yet more packages, abusing legitimate release paths — npm lifecycle scripts, the Bun runtime, GitHub trusted publishing, and OIDC authentication.
- Each newly poisoned package becomes a launch pad for the next. The chain reaction needs no further attacker action.
In a particularly brazen twist, the malware creates a brand-new public GitHub repository named “Shai-Hulud” under the victim’s own account and commits the stolen secrets into it — exposing them for anyone on the internet to find. An unexpected repo by that name appearing in your account is a flashing red light.
The scale is the story
This is not a handful of bad packages. On 11 May 2026, Microsoft’s researchers identified a major resurgence — tracked as Mini Shai-Hulud — that compromised more than 170 npm packages and two Python (PyPI) packages across 404 malicious versions, attributed to a group it calls TeamPCP. Then came the detail that captures the whole problem: in one automated burst on 19 May, the campaign published over 300 malicious package versions across 323 packages in just 22 minutes. No human team works that fast. A worm does.
Who actually gets hurt
A supply-chain attack ripples outward. The immediate victims are developers whose credentials are stolen. Next are the companies that unknowingly build their apps on a poisoned package. And finally the end users — ordinary people running an app that, somewhere deep in its thousands of dependencies, now contains hostile code. Most will never know the chain that reached them.
What developers should do now
- Rotate exposed credentials — any npm and cloud tokens that may have touched an affected machine or pipeline.
- Switch to short-lived, tightly-scoped credentials instead of long-lived all-access tokens.
- Turn on two-factor authentication for publishing.
- Pin dependencies to known-good versions rather than auto-accepting the latest.
- Watch for a rogue “Shai-Hulud” repository appearing under your accounts.
Frequently asked questions
What is a software supply-chain attack?
Instead of attacking a target directly, criminals compromise a trusted component the target depends on — here, an open-source package — so the malicious code arrives through a channel everyone trusts.
Why is a “worm” worse than a normal malicious package?
A normal bad package has to be planted by hand. A worm replicates itself — each infection automatically creates more — so it spreads at machine speed and scale.
I’m not a developer. Am I affected?
Possibly, indirectly: apps you use may be built on compromised packages. The fix is upstream, with developers and platforms, but keeping your apps and devices updated helps.
The bigger picture
Shai-Hulud is a reminder that the software you trust is assembled from thousands of parts written by people you will never meet — and that securing that assembly line is now one of the central problems in cybersecurity. The worm didn’t break in by brute force; it walked in through the trusted front door of the open-source ecosystem, and then taught itself to keep walking.