The npm Worm That Puts Itself Back Every Time You Patch a Package

In September 2025 the npm registry did something nobody expected. Packages began updating themselves. No maintainer ran npm publish. No pull request got merged. New versions just appeared, each carrying a hidden payload that would publish even more versions of more packages on more machines with no human touching anything.

Between September 14 and 18 that year more than 500 package versions were altered. The authors left a calling card. Every stolen credential was uploaded to a public GitHub repository named Shai-Hulud, after the apex predator in Frank Herbert’s Dune. The name was the point. This was not a scraper. It was an organism.

The worm got faster and meaner

Two months later a larger variant, Shai-Hulud 2.0, backdoored 796 packages in a single run. It moved earlier into the install process so the trigger could not be blocked by developer hooks. And if it could not find credentials worth stealing or a route to spread, it deleted the user’s home directory on its way out.

The escalation is the story. Version one was a proof of concept. Version two was a weapon. The gap between them was measured in weeks, not years.

By spring of 2026 the next offspring, Mini Shai-Hulud, had stopped hunting generic developer secrets. It targeted credentials belonging to Claude, Codex, Cursor, and Gemini specifically. The reasoning was cold and correct. AI coding tools work on the most interesting projects, which makes the developers using them the richest targets in the supply chain.

The latest variant, ChainDrop, surfaced in August 2026 and kept refining the same trick. Each generation is smaller, faster, and more surgical than the last.

The registry is the blast radius

This is why a package registry is not a catalog. It is an execution environment with a public write surface. When a worm can publish to that surface, it controls every downstream install, cache, and build that trusts it. The registry becomes the attack, not the delivery mechanism.

Scanners look for bad packages after they exist. A worm that writes its own packages does not care. The real defense is hardening the registry itself and the supply chain around it. Sigstore and Cosign let teams sign artifacts so a tampered package fails verification before it runs. SBOMs tell you precisely what is in your build, so a compromised dependency is visible instead of hidden.

Watch what runs at install time. A lifecycle script in a dependency is code executing on your machine. If it is not pinned, signed, and reviewed, it is an unpatched door. A dependency manager that runs arbitrary code by default is an execution engine with no safety rail.

This is also why provenance matters. If you cannot tell who published a package and what signed it, you cannot tell whether the version you installed is the one someone reviewed. Provenance turns a blind trust decision into a verifiable one.

Trust the registry, or lose the pipeline

The lesson is blunt. Whoever controls the package registry controls the pipeline. If you can publish to it, you own everything that installs from it. That is a supply chain attack with no malware file to scan, because the malware is the package manager.

Teams that treat registries as replaceable infrastructure get burned. Teams that pin versions, verify signatures, and scrutinize install scripts keep a working build. The gap between those two outcomes is a small amount of discipline applied early.

The worm is still evolving. The question is not whether it will come back. It is whether your next install can tell the difference.

There is a deeper change here worth naming. A package manager is a trust boundary, and for years nobody treated it like one. The npm worm did not exploit a vulnerable library. It exploited the assumption that the registry is a neutral place where code waits to be installed. Attackers no longer need to find a bug in your dependencies. They can become the dependency.

The practical response is to assume the registry is already hostile and build from a position of verification. That means pinning exact versions, refusing install scripts you did not write, signing the artifacts you produce, and publishing an SBOM so a downstream team can check what you shipped. It also means accepting that the clock is on the attacker’s side.

Most teams will not get to zero risk. They can get to a position where a rewritten package fails loudly instead of silently.

Supply chain accountability runs through this. The 2026 State of Enterprise Infrastructure report covers what organisations are actually absorbing and which tooling holds up.

Related reading. Attackers Chained Three JFrog Artifactory Flaws Into Full Admin Control. Platform Engineering Needs an Internal Developer Platform ROI Case, Not Another Portal. Patching vCenter Is Not Enough. CISA Says Ransomware Gangs Are Already In.. The 2026 State of Enterprise Infrastructure.