A self-propagating worm dubbed ChainDrop compromised hundreds of popular npm packages, marking a meaningful escalation in how software supply chain attacks scale. It follows an August incident in which several widely used packages, including keyv, were compromised and used to distribute a backdoor.

The mechanism is what makes ChainDrop notable. Previous npm compromises — including the March 2026 axios incident, where an attacker hijacked the lead maintainer's account and pushed poisoned releases across both the 1.x and legacy 0.x branches within 39 minutes — required the attacker to compromise each maintainer individually. ChainDrop automates that step.

How the propagation loop works

The pattern is a closed loop, and each stage feeds the next:

  1. Initial compromise. A maintainer account is taken over, or a package is published under a typosquatted name that developers install by mistake.
  2. Install-time execution. The malicious payload runs during package installation via lifecycle scripts, in the context of whatever machine is doing the install — frequently a CI runner.
  3. Credential harvesting. The payload sweeps the environment for anything reusable: environment variables, ~/.npmrc tokens, cloud provider credential files, SSH private keys, Kubernetes service account tokens, CI secrets.
  4. Republish. Any npm publish token it finds is used immediately to push trojanised versions of every package that token can write to.
  5. Repeat. Those new packages are installed by their downstream consumers, and the loop runs again — with no attacker involvement.

The economics change completely when propagation is automatic. An attacker who compromises one moderately popular maintainer can reach hundreds of packages without ever touching a keyboard again.

Zero CVEs, by design

One tracking effort counted 59 supply chain campaigns and 657 malicious packages across 2026, with zero CVEs assigned. That is not an oversight in the tracking. Malicious packages are not vulnerabilities in the CVE sense — there is no flawed code to fix, because the code is doing exactly what its author intended.

This breaks a lot of security programmes. If your dependency risk process is "run a scanner, look for CVEs, patch the findings," it will report a clean bill of health on a fully backdoored dependency tree. Software composition analysis tools that only match known-vulnerable version ranges are structurally blind to this attack.

What ChainDrop went after

Across the 2026 campaigns, the objective has been consistent: credential theft, with cloud keys, SSH keys, Kubernetes secrets and environment variables targeted in nearly every case. That target list tells you where the attacker intends to go next. Nobody steals a Kubernetes service account token to sell it — they steal it to move into the cluster.

Controls that actually work

Disable lifecycle scripts in CI

The overwhelming majority of install-time payloads execute through preinstall, install or postinstall hooks. Running your CI installs with npm ci --ignore-scripts removes that execution path entirely. Some packages legitimately need build scripts; allowlist those specifically rather than leaving the door open for the whole tree.

Commit lockfiles and enforce them

Use npm ci, never npm install, in automated pipelines. npm ci installs exactly what the lockfile pins and fails if the lockfile and manifest disagree. This does not protect you from a poisoned version you have already pinned, but it stops a compromised release from silently arriving in a build that was fine yesterday.

Add a cooldown on new versions

Most malicious releases are detected and pulled within hours to days. A policy that refuses to auto-adopt any package version published less than 72 hours ago removes a large fraction of the exposure window at almost no cost. Several registry proxies support this natively.

Kill long-lived credentials in CI

This is the highest-value change. A payload that harvests an environment full of static cloud keys gets durable access. A payload that harvests a short-lived OIDC token gets something that expires in minutes and is scoped to one repository. Migrate to workload identity federation with your cloud provider, and remove static keys from CI entirely.

Restrict egress from build runners

Build runners generally need to reach your registry, your package registries and your artefact store. They do not need arbitrary internet access. An egress allowlist stops exfiltration even when execution succeeds — and it turns a silent theft into a blocked-connection alert.

If you think you were affected

  • Rotate every credential that has ever been present in a CI environment during the exposure window. Not the ones you think were used — all of them.
  • Audit npm publish tokens across your organisation and revoke any that are not actively needed. Enforce 2FA for publishing.
  • Review your own published packages for versions you did not authorise.
  • Check cloud audit logs for API calls from unfamiliar IP addresses or user agents during and after the window.
  • Pull your dependency tree and compare installed package hashes against registry values for the versions you expect.

The uncomfortable takeaway is that the trust model of open package registries has not changed to match how they are now being attacked. Until it does, the practical defence is to assume any dependency can execute hostile code at install time and to build your pipeline so that assumption is survivable.