← All attack breakdowns
Supply chain Latest wave: 4 August 2026

Shai-Hulud

Also tracked as CHAINDROP

A self-replicating npm worm that turned maintainers into distribution

~440 packages · 2,200+ versions · under one hour

Shai-Hulud is a self-propagating worm that spreads through the npm registry. It does not exploit a flaw in npm. It steals a maintainer's credentials, then uses their own publishing rights to ship poisoned versions of every package they control.

The August 2026 wave began with a hijacked maintainer account behind the keyv and cacheable families and reached roughly 440 packages across 2,200+ versions within an hour. Packages in the blast radius include flat-cache and file-entry-cache, together over a billion weekly downloads.

What makes it worth studying is the activation condition: the worm only fires when it finds an npm token that can publish *and* skips two-factor authentication. Everything else is ordinary automation.

The attack chain

4 of 5 stages are broken by controls we verify. Where nothing we check would have helped, the stage says so.

1

Maintainer account hijack

Entry is a compromised maintainer GitHub account — not a registry vulnerability. Everything downstream is the attacker using legitimate access.

Broken by

  • GitHub Org 2FA Required
2

Credential harvesting on the developer machine

A collector component sweeps 300+ patterns: GitHub and npm tokens, SSH keys, cloud and Kubernetes credentials, and AI tool keys. Findings are encrypted and exfiltrated.

Broken by

  • GitHub Secret Scanning
  • GitHub Push Protection

What we can't verify

We verify that leaked secrets are caught in your repositories. We cannot see what is sitting on a developer's laptop.

3

Token selection — the activation condition

The worm activates only on npm tokens holding package write permission AND the 2FA bypass flag. Automation tokens that skip the second factor are what it hunts.

What we can't verify

npm exposes no public API for per-package publish requirements or token flags, so we cannot verify this — and we would rather say so than ship a checkbox you fill in yourself. Removing bypass-2FA automation tokens is the single highest-value fix here.

4

Self-propagation

For every package the stolen identity controls: pull the latest tarball, inject the payload, patch package.json to add a preinstall hook, bump the patch version, republish. No human involved — which is how 440 packages fall in an hour.

Broken by

  • Published Build Provenance
  • Releases Linked to Verified Source
5

Execution on every downstream install

The injected preinstall hook runs before installation completes on every machine that pulls the package. Later waves also wrote agent and editor config (.claude/settings.json, .vscode/tasks.json) into repositories as an additional execution path.

Broken by

  • No Install-Time Scripts

How we verify the layer exists

Each of these reads a specific field from a provider's own API. The exact field is listed in our methodology.

Org-wide 2FA required

Reads two_factor_requirement_enabled on your organization. Raises the cost of stage 1, the account takeover the whole chain depends on.

No install-time scripts

Reads hasInstallScript on your latest published npm release. A package with no install hooks cannot be the worm's execution stage — this is precisely what stage 5 abuses.

Published build provenance

Verifies your latest release carries Sigstore or Trusted Publishing provenance, so a version pushed from a stolen long-lived token is distinguishable from one built by your CI.

Releases linked to verified source

Confirms the repository named inside that provenance belongs to the organization whose hardening we verify — closing the chain from install back to reviewed source.

What passing these checks does not mean

  • ·We cannot verify npm token flags, including the bypass-2FA setting the worm keys on. That control is yours to enforce.
  • ·Provenance proves where an artifact came from, not that the build was uncompromised. A stolen OIDC token from a hijacked workflow produces valid provenance — which is why the CI hardening checks matter alongside it.
  • ·We read your published packages, not your developers' machines. Credential hygiene at the endpoint is outside what any read-only API can show.

Sources

Would these controls hold in your environment?

Connect read-only and find out in 60 seconds. Free.

Check my posture