Three times in eight months, the same npm worm playbook worked. Different attackers, different packages, the same mechanic, and the same window of time in between publication and detection that made each one possible. If you’re asking what an npm worm actually is and why the pattern keeps repeating instead of getting fixed, this is the honest answer, incidents, mechanics, and the one gap even a solid defensive framework still leaves open.
What Is an npm Worm?
An npm worm is a piece of malicious code published to the npm registry that automatically spreads itself to other packages once it runs, typically by stealing a maintainer’s publishing credentials and using them to inject the same payload into every package that maintainer controls. It’s “worm” in the classic sense: it doesn’t wait for someone to install it deliberately, it propagates on its own, package to package, account to account, at machine speed.
That self-propagation is what separates an npm worm incident from an ordinary malicious package. A single bad package is a needle in a haystack. An npm worm turns every compromised maintainer into a new distribution point, and the haystack starts generating its own needles.
The Biggest npm Worm Incidents So Far
The last year gave the npm worm pattern three real-world test runs, each one more efficient than the last:
- Shai-Hulud (September 2025). The first documented self-propagating npm worm. It compromised maintainer credentials, then used them to publish malicious versions of every package under that maintainer’s control, turning developers themselves into the delivery mechanism for the next stage of the worm.
- axios (March 2026). Nation-state malware hidden inside a package pulled roughly 100 million times a week. Not a worm in the strict propagation sense, but proof that the same npm ecosystem trust model Shai-Hulud exploited could carry a payload at genuinely massive scale.
- SAP npm (April 2026). Described at the time as a mini Shai-Hulud: the same worm pattern, repeated at scale, less than a year after the original incident. The mechanism hadn’t changed. The defenses mostly hadn’t either.
Three npm worm incidents, one repeating pattern: compromise a trusted publisher, use their credentials to propagate automatically, and count on the gap between publication and community detection to do the rest.
The Pattern That Repeats
Strip away the specifics and every npm worm incident follows the same four beats:
- Account compromise. A maintainer’s publishing token, npm login, or CI credential gets stolen, usually through phishing, a leaked secret, or a compromised dependency further up their own chain.
- Silent injection. The attacker pushes a new version of a legitimate, trusted package with malicious code added, often inside a postinstall or other lifecycle script that runs automatically the moment someone installs it.
- Automatic propagation. If the compromised maintainer controls other packages, or if the malicious script itself harvests further credentials, the worm spreads to the next package and the next maintainer without further action from the attacker.
- The detection lag. The package sits live on the registry, installable by anyone, until someone notices, reports it, and it gets pulled. That lag, hours for some incidents, days for others, is the entire window the worm needs.
Recognizing that fourth beat is what actually matters for defense. Every mitigation strategy for an npm worm incident is, at its core, an attempt to shrink or bypass that detection lag.
A Framework Worth Citing: SIP’s Answer to the Cooldown Problem
Not every response to this pattern comes from a vendor. One of the clearest is SIP, Mohammad-Ali A’râbi’s Security Immediate Plan, a five-control emergency framework for software supply chain risk that came out of a very practical question asked at the end of a SafeDev session: “If we can only do a few things, what should we do first?”
SIP’s second control is aimed squarely at the npm worm problem: freeze unvetted dependencies with a five-day cooldown period, and disable lifecycle scripts so a malicious postinstall can’t execute automatically during installation. In practice, that’s min-release-age=5 et ignore-scripts=true in a project’s .npmrc, enforced in CI so a lockfile can’t quietly resolve a package published yesterday. It’s a genuinely sound, low-effort control, and it directly targets the same detection lag every npm worm incident depends on. Dive in:
Where the Cooldown Window Still Leaves a Gap
A cooldown period is a bet: that the community will notice and report a malicious package before the waiting period ends. Most of the time, that bet pays off. A meaningful share of compromised packages are flagged within the first few days of publication, which is exactly why a five-day window is a reasonable default.
But an npm worm doesn’t behave like a typical malicious package, and that changes what a fixed cooldown can and can’t do for you.
To be precise about speed: a fast-propagating worm doesn’t actually defeat the cooldown itself. If you enforce a strict minimum release age, packages published during that initial wave are still too new to enter a build, no matter how many packages the worm compromises in the meantime. Speed matters, but it matters for everyone downstream who isn’t running a cooldown, not for beating one that’s already enforced.
The real limitation is patience. A more careful payload can sit dormant past the cooldown period, activating only once the days have cleared and the package has aged into the “trusted” zone, precisely because it knows a cooldown is watching. That’s the scenario where a fixed cooldown alone isn’t enough, and exactly where something like MEW’s evidence-based detection needs to sit alongside it, not instead of it.
Neither failure mode is a flaw in SIP’s thinking. A cooldown is a community-detection bet, and community detection has a floor: it can’t catch what nobody has reported yet. That’s not a gap unique to SIP, it’s a structural limit of any defense that waits for a signature, an advisory, or a public report to exist before acting.
How MEW Closes the Cooldown-Window Gap
Hoc est praecisely hiatus Monitum Praecox de Programmatibus Maligni (MEW) Xygeni is built to close. Instead of waiting for community reports or a published signature, MEW continuously scans NPM, PyPI, and Maven as new packages and versions are published, analyzing behavior rather than matching against known threats. When something looks malicious, it gets quarantined and the finding is confirmed by security researchers before public disclosure, not after.
That distinction matters for both of the npm worm failure modes above. Against a fast-propagating worm, pre-signature detection doesn’t need the five days a cooldown assumes it has. Against a patient, dormant payload, MEW’s behavioral analysis isn’t looking for age or reputation, it’s looking for what the code actually does, so waiting out a cooldown window buys an attacker nothing.
MEW’s Dependency Firewall extends this to the point of installation itself, blocking a malicious package in real time even if it slipped past earlier checks, and the same detection layer covers the CI/CD side of an npm worm incident: the unlock-branch, inject, re-lock pattern that lets an attacker push a malicious commit and quietly cover their tracks, with a full audit trail if it happens anyway.
SIP and MEW Are Answering the Same Question, at Different Layers
None of this makes SIP’s cooldown control wrong, and it’s worth saying plainly: a five-day cooldown with lifecycle scripts disabled is still one of the fastest, cheapest defenses a team can put in place against an ordinary npm worm incident, and it belongs in any serious supply chain hardening plan. What it can’t do, by design, is catch what the community hasn’t found yet. That’s a job for continuous, behavior-based detection running underneath the cooldown, not instead of it.
Layered together, the two approaches cover both ends of the same problem: SIP hardens the build pipeline, the dependency freeze, and the container image around a known, disclosed threat landscape, while MEW’s pre-signature detection covers the npm worm incidents that haven’t been disclosed yet, the ones a cooldown window, by its own logic, can’t see coming.
FAQ
What is an npm worm, in one sentence?
Malicious code published to npm that automatically spreads itself to other packages, typically by stealing a maintainer’s credentials and using them to inject the same payload elsewhere, without further action from the attacker.
Is every malicious npm package an npm worm?
No. A malicious package that doesn’t propagate on its own is a supply chain attack, but not a worm. What defines an npm worm incident specifically is the self-propagation step: one compromise leading automatically to the next.
Does a dependency cooldown period stop an npm worm?
It significantly reduces risk, since most malicious packages are reported within the first few days of publication. But a cooldown is a bet on community detection speed, and a fast-propagating or deliberately dormant npm worm can be built specifically to beat that window.
What actually catches an npm worm before a cooldown period would?
Continuous, behavior-based scanning that doesn’t depend on a signature or a public report existing yet. That’s the specific gap pre-signature detection tools like Xygeni’s MEW are built to close.
