flawopen.com/Incidents/Shai-Hulud npm worm

Shai-Hulud: the npm worm that published itself

Key terms on this page

lifecycle script

A command npm runs automatically during installation — preinstall, install, postinstall. It executes with the privileges of whoever ran npm install, before any of the package's code is ever imported.

supply chain attack

Compromising a dependency in order to reach everyone who consumes it, rather than attacking the final target directly.

worm

Malware that propagates without an operator. Each new infection independently produces the next, which is why growth is exponential rather than linear.

What happened

In mid-September 2025 the npm registry was hit by a self-replicating supply chain worm that researchers named Shai-Hulud, after the sandworms of Dune. It compromised hundreds of packages — reporting at the time put the figure in the region of 500 — and it did so with no human operator directing each step.

The entry point was mundane: a phishing email dressed up as an npm security notice, which harvested a package maintainer's credentials. What made the incident significant was everything that happened after that first account fell.

This was a distinct event from the npm compromise roughly a week earlier, in which a separate maintainer was phished and widely-depended-upon packages were trojanised with cryptocurrency-stealing code. The two are often conflated because they occurred in the same month and both began with maintainer phishing.

The propagation loop

The worm's design is the whole story. Each infected install performed four steps, the last of which produced the next generation:

That fourth step is what separates this from a conventional malicious-package incident. The attacker did not need to compromise hundreds of maintainers. They needed to compromise one, and let the loop find the rest.

Why lifecycle scripts are the crux

A dependency you never call still runs code on your machine at install time. That is the design decision the whole attack rests on.

// package.json of a trojanised release
{
  "name": "some-popular-util",
  "version": "4.1.3",
  "scripts": {
    // runs automatically on install,
    // with your shell privileges
    "preinstall": "node bundle.js"
  }
}

# Install without running any
# lifecycle scripts:
npm ci --ignore-scripts

# Or make it the default for the
# project / CI environment:
npm config set ignore-scripts true

# Note: some packages with native
# builds genuinely need scripts.
# Allowlist those deliberately.

Defences that would have mattered

• ✓Disable install scripts by default in CI. npm ci --ignore-scripts neutralises the execution primitive this worm depended on. Allowlist the small number of dependencies that truly need a native build step.
• ✓Pin with a lockfile and use npm ci, not npm install. A lockfile means a freshly published malicious version is not silently pulled into your build the hour it appears.
• ✓Stop using long-lived publish tokens. Trusted publishing / OIDC-based workflows mean there is no static token sitting in an environment variable for a scanner to find. This attacks the propagation step directly.
• ✓Require phishing-resistant MFA for maintainer accounts. The initial compromise was credential phishing. Hardware-backed WebAuthn does not forward to a lookalike domain the way a typed OTP does.
• ✓Scope CI credentials down and give them short lives. Assume a build runner will eventually execute hostile code, and size the credentials it holds accordingly.
• ✓Add a cooldown on new versions. Refusing to auto-adopt releases published in the last 24–72 hours costs little and removes you from the window in which these campaigns do their damage.

The transferable lesson

Most dependency-security tooling is built to answer "does this package have a known CVE?". A freshly trojanised version of a package you already trust has no CVE, a legitimate history, and a maintainer in good standing. Shai-Hulud is the argument for treating installation itself as the security boundary — controlling what executes, what credentials are within reach when it does, and how quickly new versions are adopted — rather than relying on after-the-fact vulnerability lists.

FAQ

Sources

• Unit 42 (Palo Alto Networks) — "Shai-Hulud" worm compromises npm ecosystem in supply chain attack
• Checkmarx — npm hit by Shai-Hulud, the self-replicating supply chain attack
• Trend Micro — what we know about the npm supply chain attack
• Panther — Shai-Hulud npm supply chain attack: what to know
• npm docs — npm ci
• npm docs — the ignore-scripts configuration option
• CWE-506 — Embedded Malicious Code