Two campaigns, one week apart
On April 22nd, a self-propagating campaign researchers dubbed "Shai-Hulud: The Third Coming" began spreading through the npm registry. A week later, on April 29th, a second wave — "Mini Shai-Hulud" — followed, this time hitting entire clusters of related packages at once, including well-known projects like TanStack. Both campaigns published malicious versions in coordinated phases, with obfuscated payloads designed to execute automatically during package installation.
This wasn't a one-off. It's the third or fourth major descendant of the original Shai-Hulud worm that first surfaced in September 2025 — a self-replicating attack pattern that's become disturbingly reliable: compromise one maintainer's credentials, use them to publish malicious versions of every package that maintainer controls, harvest secrets from anyone who installs the update, and use those stolen credentials to spread to the next maintainer.
Why this keeps working
The mechanism is almost boringly simple, which is exactly why it's effective. A maintainer's npm or GitHub account gets compromised — often through a phishing email or a leaked token, not some exotic zero-day. The attacker publishes a new version of a legitimate, trusted package with a malicious install script hidden inside. Because the package already has a large install base and a track record, most CI pipelines and developer machines pull the update automatically, no questions asked. The payload runs during npm install, before anyone's even looked at the code, harvesting GitHub tokens, npm credentials, AWS keys, and SSH keys, then using whatever it finds to repeat the process on the next maintainer's packages.
Trust, at scale, becomes the attack surface.
What actually reduces your exposure
A few practices consistently separated teams that weathered these campaigns without incident from teams that didn't:
Lockfile discipline. A committed lockfile with exact versions means a compromised patch release doesn't silently flow into your build the next time CI runs
npm install.Version cooldowns. Some teams now delay adopting brand-new package versions for 24–72 hours by policy, specifically to give the community time to catch a malicious release before it reaches production.
Restrict broad semver ranges in package.json where you can, particularly for packages deep in your dependency tree that you don't actively monitor.
Scope credentials aggressively. CI tokens and npm publish tokens with the narrowest possible permissions limit how much damage a single compromised secret can do.
Continuous SBOM monitoring, so when a campaign is disclosed, you can immediately check whether an affected package or version is anywhere in what you actually ship — not just scan your direct dependencies and hope.
The uncomfortable part
None of this is exotic advice. It's the same supply-chain hygiene that's been recommended for years. What changed is the frequency and the blast radius — these worms don't wait for you to notice; they propagate in minutes, and the packages they hit (caching libraries, utility packages) are exactly the kind of thing sitting deep in a dependency tree that nobody reviews line by line. The defense isn't clever. It's just no longer optional.