Shai-Hulud 2.0 npm Worm Backdoors 796 Packages - Preinstall Credential Theft and Home-Directory Wiper

Identified November 24, 2025, Shai-Hulud 2.0 is a self-replicating npm worm that backdoored 796 unique packages totaling over 20 million weekly downloads and compromised roughly 1,200 organizations, including banks, government bodies, and Fortune 500 firms. There is no single CVE - CISA covered the campaign in its September 2025 alert on the widespread npm-ecosystem supply-chain compromise, and it is tracked by campaign name. This advisory covers what happened and how to govern the agents and CLIs that drive package installs across your fleet.

What happened

Shai-Hulud 2.0 is the second wave of the Shai-Hulud npm worm, distinct from the September 2025 original. The decisive change is *when* it runs. Where the original executed during the post-install lifecycle step, 2.0 injects a preinstall script, so the payload runs before installation completes and even when installation fails. A failed npm install no longer protects you - the code has already executed - which widened impact across developer machines and CI/CD runners.

The payload is a credential stealer. It harvests secrets from the local filesystem and cloud environment, exfiltrates them through public GitHub repositories, and self-replicates with no command-and-control server, using the victim's own npm credentials to backdoor further packages. The campaign created over 25,000 malicious repositories across about 350 user accounts. Its fallback is destructive: if it cannot steal credentials or secure an exfiltration channel, it attempts to delete the victim's entire home directory, turning quiet theft into data loss.

Popular projects were caught in the blast radius - packages from Zapier, ENS Domains, PostHog, and Postman were temporarily trojanized under their real names, so a routine install could pull attacker code through a trusted channel. Because no CVE maps to a fixed version, remediation is operational: rotate all developer, CI/CD, npm, GitHub, and cloud tokens, pin dependencies to known-good versions, and disable npm lifecycle scripts where possible. The durable response is to know which endpoints run the agents and CLIs that trigger installs, and govern what they do before a payload runs - the same supply-chain root cause as the sibling LiteLLM malicious PyPI release advisory.

Why this is an agentic-endpoint risk

The path to the credentials ran through ordinary package installs - and on a modern developer machine, those installs are increasingly driven by AI coding agents and CLIs, not just a human at a terminal. A coding agent that scaffolds a project, adds a dependency, or runs a build invokes npm install, and the moment a transitively backdoored package is in the tree, the preinstall payload fires inside the agent's process with its environment and reachable secrets. AI agents, MCP servers, CLIs, and secrets are part of the eight AI artifact types Anomity tracks per endpoint.

This exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. The npm install looks like a legitimate build step to network tooling, the agent process looks legitimate to EDR, and DLP sees nothing at rest because the worm reads tokens from the live environment and pushes them through GitHub's normal API surface. The question is not whether one package is patched - there is nothing to patch - it is which endpoints and pipelines run the agents and CLIs that install packages, and what secret access they perform. That is the boundary runtime governance is built to hold.

How Anomity surfaces and governs it

With no version to roll forward, the durable control is to inventory the agents and CLIs that drive installs and govern what they do with the secrets they can reach. Anomity does that in three steps.

First, inventory. Anomity inventories AI agents, MCP servers, CLIs, and secrets on every managed endpoint as part of the eight AI artifact types it tracks, then classifies them. It captures which coding-agent and CLI surfaces are present across developer machines and CI-adjacent endpoints, so you can find every place that can run npm install. Anomity collects metadata only, and secrets such as npm, GitHub, and cloud tokens are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, the Claude Code PreToolUse event - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. An agent about to invoke an install that would fire a malicious preinstall payload, or reach for a publish or cloud token, can be denied at the boundary - what runtime governance provides when there is no patch to wait for and a failed install is no longer safe.

Third, keep the record. Anomity logs the tool calls and secret access an agent performs, so an agent running an install or reaching a token is recorded against a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a campaign like Shai-Hulud 2.0 lands, you can answer which endpoints ran the affected installs and what those agents were allowed to touch - from a record, not a guess. Anomity is SOC 2 Type II and complements your Network, EDR, DLP, and GRC tooling. See how it works.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint and pipeline that runs AI coding agents and CLIs capable of npm install, and confirm none pulled a Shai-Hulud 2.0 backdoored version, including packages from Zapier, ENS Domains, PostHog, and Postman.
• Rotate all developer, CI/CD, npm, GitHub, and cloud tokens any exposed endpoint or runner could reach - assume preinstall execution means the secret was read.
• Pin dependencies to known-good versions and disable npm lifecycle scripts where possible, so a preinstall payload cannot run on the next install.
• Treat any token reachable by an agent or CLI that runs installs as exposed to untrusted input, since a transitively backdoored package executes inside the agent's process.
• Confirm install and package commands triggered by an agent are evaluated at a hook with allow/deny/log, so a malicious preinstall is stopped before it runs.
• Verify npm, GitHub, and cloud credentials are redacted on the endpoint and never centralized in plaintext, so a worm reading the live environment has nothing to capture.
• Verify every tool call and secret access is written to a 90-day audit trail and routed to your SIEM, so you can answer scope when the next npm supply-chain worm lands.
• Cross-reference this inventory against the sibling LiteLLM malicious PyPI release advisory to find endpoints exposed to more than one registry attack path.

Shai-Hulud 2.0 is a reminder that an everyday package install - increasingly driven by an AI agent or CLI - becomes a credential-theft and data-destruction path the moment a dependency is backdoored, and that moving the trigger to preinstall means a failed install is no longer safe. Rotate and re-scope the affected tokens, pin to known-good versions, then inventory the agents and CLIs your endpoints run and govern the tool calls they make at the hook. For the full picture, see the pillar guide on AI supply-chain attacks. To see Anomity govern the agent layer across your fleet, request early access.