If you’ve been paying attention to cybersecurity news or are [un]lucky enough to be in a Slack channel with some cybersecurity practitioners, you have probably heard about a new old cybersecurity threat: worms. Worms were initially made famous by large-scale email-based attacks such as the ‘I LOVE YOU’ virus way back in the last millennium (Note: It did not, in fact, love you.).

So how can an inelegant weapon from an [arguably] more civilized age be making the headlines again? Read on.

What is an npm worm?

In cybersecurity, a worm is a self-replicating piece of malware that spreads automatically between systems. An npm worm spreads through the Node Package Manager (npm) ecosystem—an online registry of JavaScript and Node.js packages—by hiding inside seemingly legitimate open-source packages. When a developer installs one of these packages, the worm executes code on their machine or Continuous Integration (CI) environment and attempts to spread further. This makes it a type of software supply chain attack, where the attacker weaponizes trusted components to reach thousands of downstream users.

Unlike a traditional virus that might require someone to open an infected file (perhaps promising worlds of affection), an npm worm piggybacks on the trust developers place in shared code. When a developer runs npm install to fetch third-party libraries, an infected package can execute malicious code during installation via "lifecycle scripts" (e.g., preinstall, install, postinstall). These scripts are intended for compiling code or preparing dependencies, but they also provide an opportunity for embedded malware to run with the same permissions as the user or CI pipeline. Once active, the worm can collect sensitive data, modify files, or search for credentials to infect additional packages—similar to how biological parasites reproduce by finding new hosts.

How npm worms spread

Npm worms exploit the interconnected nature of modern JavaScript development, where applications rely on numerous third-party and transitive dependencies. Their behavior typically follows a predictable pattern:

1. Compromise maintainers
2. Infect packages
3. Execute on developer systems
4. Self-replicate
5. Target CI/CD cloud environments

1. Compromising maintainers

Attackers often begin by obtaining credentials from a legitimate maintainer through phishing, malware, or a compromised machine. These credentials (usually an npm automation or GitHub access token, or keys to a private registry) allow the attacker to publish new versions of popular packages without raising suspicion. Once the maintainers’ account is compromised, the attacker essentially controls a trusted supply chain entry point. With just one developer’s machine compromised, the infestation can begin. 

2. Infecting packages

Once the attacker controls a (previously trusted) package, they inject malicious code or installation scripts and publish a new version to the npm registry. This code might not be easy to spot (see “Stealth and persistence” below), and the worm might publish multiple versions quickly to camouflage its activities. 

Once it’s published, any project that installs the updated package automatically executes the malicious script, and the infection spreads. 

3. Executing on developer systems

On installation, the worm scans the system for secrets: GitHub tokens, npm publish tokens, or cloud API keys that are commonly found in environment variables or config files. Some worms use automated tools (some of which, like TruffleHog, started life as cybersecurity tools to prevent secrets from leaking) to find secrets quickly. Stolen credentials are exfiltrated to an attacker-controlled server or a public GitHub repository. And if that developer maintains multiple Node packages, the worm might have discovered a whole new set of vectors.

4. Self-replication

When the worm obtains access tokens for GitHub or npm, it uses them to spread. Stolen npm tokens allow it to publish malicious versions of any packages the victim maintains. Stolen GitHub tokens may enable the worm to modify repositories or push new code, turning the victim into an unwitting carrier and expanding the infection chain. The malware is now in a whole new set of places along with ‘patient zero’s’ packages.

5. Targeting CI/CD and cloud environments

If a worm finds itself running in a CI/CD environment (such as GitHub Actions) it targets high-value secrets stored there or injects malicious workflow files or new steps that automatically leak credentials. This gives the attacker access well beyond a single workstation and the ability to push poisoned builds or artifacts. Potentially paving the way for a SolarWinds-style attack (although to the author’s best knowledge, this has not happened yet).

Stealth and persistence

With all the focus on cybersecurity and supply chain health, not to mention multiple tools and billions of dollars spent, why are worms resurgent? Apart from the novel vector, worms evade detection by running obfuscated code, executing silently in the background, or using runtimes not typically monitored by security tools (see the Shai-Hulud description below). This makes infections harder to spot and allows the worm to operate for longer. Typically, however, due to the large number of package versions or repositories the worms have created, so far they have been identified (if not stopped) within hours or days. 

Shai-Hulud attacks: A real-world example

One of the most notable NPM worms to date is Shai-Hulud, named after the giant sandworms in Dune (a little ironic, since a 400-meter-long worm might be hard to miss). First appearing in September 2025, it became the first truly wormable npm supply chain attack, capable of autonomous, large-scale propagation.

Self-spreading behavior

Shai-Hulud followed the general infection pattern described above, but executed it with unusual automation and speed. Upon infecting a developer machine, it harvested GitHub and npm tokens, then:

1. Created new public repositories named “Shai-Hulud” to store stolen credentials
2. Inserted malicious GitHub Actions workflows into any repositories the victim had access to, causing those repos to leak secrets during CI runs
3. Published infected versions of any npm packages the victim maintained, expanding its reach far beyond the initial target

Each newly infected maintainer became a fresh source of propagation, amplifying the worm’s spread.

Scale of the outbreak

Shai-Hulud spread in multiple waves. Wave one occurred in September 2025 when hundreds of packages were compromised within days, including widely-used libraries such as @ctrl/tinycolor and those from reputable cybersecurity organizations, including CrowdStrike. Just when you thought it was safe to get back into the desert (apologies for the terrible film references), wave two arrived in late November 2025, affecting over 500 packages and 700 versions from companies like Zapier, AsyncAPI, Postman, PostHog, and ENS Domains. Analysts estimate that more than 25,000 GitHub repositories were touched through automated replication and credential theft.

Shai-Hulud 2.0 Advancements

The November 2025 wave of Shai-Hulud introduced notable innovations:

• Use of the Bun runtime: During installation, packages ran a setup_bun.js script that silently installed Bun and executed an enormous, heavily obfuscated payload, bypassing security tools that monitor Node.js processes.
  
• Background execution: The payload ran as a detached process with no output, making detection far harder.
  
• Environment awareness: The worm adjusted its actions depending on whether it ran on a developer machine or CI system, prioritizing the extraction of high-value secrets.

Destructive behavior

If Shai-Hulud couldn’t find credentials to continue spreading—such as when executed on a machine without tokens—it executed a destructive fallback: wiping files in the user’s home directory. Though not its primary objective, this “fail-closed” behavior caused significant damage in some environments. 

Overall impact of Shai-Hulud

A single infection could lead to credential theft across the cloud, GitHub, and internal systems, the compromise of any packages the victim maintains, and secret leakage of secrets through poisoned CI workflows. Given the popularity of some infected packages, this also led to large-scale downstream compromise across many organizations, which in turn led to more compromised packages, and on and on. 

In short, Shai-Hulud demonstrated how quickly and deeply a wormable package attack can penetrate the software supply chain.

Why npm worms are so dangerous

Despite following an older attack pattern, npm worms pose an outsized risk in the software supply chain due to:

• The scale of npm: Modern applications depend on hundreds of packages, many of which are pulled in indirectly through transitive dependencies. A single malicious update can ripple through thousands of projects.
  
• Implicit trust: Developers often trust well-known packages or maintainers without verifying every update.
  
• Long-term impact of leaked secrets: Even after the malware is removed, compromised credentials can enable future breaches.
  
• Ecosystem-wide blast radius: Once a maintainer is compromised, all their projects—and all users of those projects—become potential victims.
  

These factors make npm worms suited for high-impact, fast-moving supply chain attacks, and should give us all cause to look at other potential vectors, such as Python package managers.

Wasn’t two-factor authentication supposed to mitigate this risk? 

Yes and no. Most major package management systems have mandated two-factor authentication to upload packages to their registries interactively. However, to facilitate automation, developers can create authentication tokens to enable tools to upload and publish packages on their behalf. These tokens are often long-lived, and so their loss enables malicious actors to operate with stolen credentials for extended periods. At Endor labs, we strongly support the use of OIDC tokens where possible (see the article linked below). 

Although technology plays an important part in protecting you from worms, it’s just part of the story. 

The importance of hygiene

Just as humans avoid parasitic worms through basic hygiene, organizations can protect themselves from software supply chain parasites by understanding how they spread and maintaining good development hygiene, especially around credential handling and dependency management.

For deeper, actionable guidance, see our guide to implementing protection from NPM software supply chain attacks.