A self-spreading npm worm poisoned hundreds of packages to steal cloud and GitHub tokens

The npm install step has never been the only place a poisoned package can run its code, but most supply-chain defenses still act as if it were. The worm that tore through npm on August 4, 2026 makes the gap concrete. Its operators did not just hide malware in a preinstall script. They also dropped a hook for Claude Code and an auto-run task for Visual Studio Code, so the payload can fire when a developer simply opens the project folder. Install-time scanning was never going to catch that.

This is the same self-replicating pattern we have tracked in npm before, industrialized. Researchers at SafeDep, Socket and Aikido documented the outbreak; The Hacker News ties it to the Shai-Hulud worm family, while BleepingComputer reports the same campaign under the name ChainDrop. Different names, one event, and the accounts disagree on scale in ways worth stating plainly.

What actually happened

The first poisoned release was [email protected]. Per The Hacker News, its authors wired a preinstall hook to launch a dropped setup.mjs, tucked a companion file called Math_Symbol.js beside it, and left the genuine compiled library in place so the package kept working for anyone who pulled it. After that it needed no human hand. SafeDep clocked it hopping to a new organization every two to seven minutes, then wrapping up its publishing spree in about half an hour, each fresh malicious version signed with npm tokens it had already stolen.

The scale depends on who counted. SafeDep started at 79 package names and 353 bad versions, then widened its tally to 420 packages and 1,684 versions spanning nine organizations. Aikido, mapping separately, put it at 868 or more packages over 1,381 versions. BleepingComputer's figure is blunter: north of 1,300 packages that pull around two billion downloads a month. Nobody has a complete package-by-package map yet, so read every number here as a floor, not a ceiling.

What it grabs is wide. The stealer goes after tokens and keys for GitHub and npm, the major clouds (AWS, GCP, Azure), HashiCorp Vault, Kubernetes, and databases, plus any private keys within reach. It also scrapes GitHub Actions runner memory for the short-lived tokens a workflow holds while it runs. Before a credential leaves the host, BleepingComputer notes, the malware confirms it is live by calling npm's whoami, then pulls down the Bun runtime to run its payload. If your build pipeline touched an affected release, assume the secrets that pipeline could reach are already gone.

The trigger moved off npm install

Here is the part the wire coverage mostly noted and moved past. Inside the malicious repos sat two extra config files. One was a .claude/settings.json whose SessionStart hook reached into the .vscode/ directory to run a script there. The other was a .vscode/tasks.json defining an Environment Setup task with runOn: folderOpen. Read that again. The attacker is no longer betting only on npm install running a lifecycle script. They are betting on you opening the folder in your editor, or starting an AI coding-agent session inside it.

We have written about each half of this before. Editor auto-tasks that run on folder open were the whole story in our coverage of an npm stealer that ran when you opened the project, and AI coding agents as an unmonitored path onto a developer's machine ran through the clean-repo reverse-shell case and three agent attacks in a single week. This worm fuses both into one campaign. That is the shift: your threat model for a cloned or updated dependency now has to include the editor and the agent, not just the package manager.

The one thing standing between this and silent execution is workspace trust. VS Code blocks automatic tasks in a workspace you have not trusted, and Claude Code applies its own workspace-trust prompt. Those prompts exist for exactly this. Treat a trust dialog on an unfamiliar repository as a security decision, not a nuisance to click through, and keep VS Code's Restricted Mode on for code you are only reviewing.

Valid provenance did not save anyone

The uncomfortable detail: the poisoned releases shipped with legitimate-looking attestation, valid OpenID Connect identity and SLSA provenance, produced by real GitHub Actions runs. The signature proved the build ran where it claimed. It said nothing about whether the source that went into the build was safe, because the source was already compromised. We flagged this exact failure mode when AsyncAPI's npm packages were compromised and shipped malware with valid provenance, and it holds again here. Provenance answers whether a package was built by the pipeline you expect, not whether the code is safe to run. If your intake gate treats a green provenance check as a safety verdict, this worm walked straight through it.

The token-rotation trap

Rotating exposed credentials is the obvious move, and it is the right one, but sequence matters more than usual here. SafeDep warns that the malware watches for revocation and treats it as a starting gun: kill a token first and you can hand control to a local handler the attacker planted, one that fires before you have cleaned the box. Do it in this order instead. Find and strip out the planted watcher and any lifecycle hook, isolate the affected host or runner, and only then rotate. Rotate on a machine that is still dirty and you are running the attacker's script for them.

Contain and detect now

If your organization ships or consumes npm packages, work this in order.

• Diff the packages your lockfiles actually resolve to against the affected-package lists SafeDep and Aikido have published. A clean direct dependency proves nothing, since the worm rode in through transitive ones.
• Any laptop, CI runner or container that installed, or even opened, one of these releases should be treated as burned. Rebuild it from a known-good image instead of cleaning it in place.
• Turn off install scripts wherever you can. An ignore-scripts posture shuts the preinstall door this worm walks through.
• Hunt for the editor and agent artifacts: an unexpected .claude/settings.json with a SessionStart hook, a .vscode/tasks.json with runOn: folderOpen, or new setup.mjs and Math_Symbol.js files in a repo that never had them.
• Watch outbound traffic for the reported exfiltration domain npm-cache[.]com, for unexpected calls to npm's whoami endpoint from build hosts, and for a Bun runtime being pulled onto a machine that does not use it.
• Sequence your response: pull the hooks and isolate the host before you revoke or rotate tokens, so revocation cannot trip the attacker's watcher.

The lesson is not that npm is dangerous. It is that the boundary you have to defend has moved. For years the supply-chain question was whether a package would run something bad during installation. This worm answers a newer question: what runs when your editor or your AI agent opens a repository you just pulled. Detection that only watches the install step is now watching the wrong door. Managed detection that correlates process, network and credential-use signals across developer and build hosts, mapped to MITRE ATT&CK, is what catches the token theft in the window before the damage is done. If you want the background on that model, our explainer on what a SIEM does covers it.