ChainDrop npm Supply-Chain Attack: A Self-Propagating Worm That Hunts Your CI/CD Secrets

In under four hours on August 4, 2026, a single compromised maintainer account turned into 2,212 malicious package versions across 440 npm packages — some with hundreds of millions of weekly downloads. The campaign, dubbed ChainDrop, isn’t a bad package you can just avoid. It’s a self-propagating worm that steals developer and CI/CD credentials and uses them to infect the next batch of packages automatically. If your build pipeline pulls from npm — and it does — this is the threat model you should be designing against.

What happened

ChainDrop began with 11 malware carriers in the widely used keyv and cacheable namespaces, after their maintainer’s GitHub account was compromised. From that foothold the malware spread on its own: it used stolen npm and GitHub credentials to download the latest tarballs of other packages, inject its payload, add a preinstall hook, bump the patch version, and republish. In under four hours it had pushed 2,212 malicious versions, and propagation carried it into 433 additional packages. Combined, the initially compromised packages pull in more than 500 million downloads a week.

This is the important shift: ChainDrop is a worm, in the lineage of last year’s Shai-Hulud attacks. Every account it steals becomes a new launch point, and every CI/CD pipeline it lands in is both a victim and a spreader. One phished or leaked token doesn’t compromise one package — it compromises a chain of them, fast.

Why this is worse than a typical malicious package

Three design choices make ChainDrop nasty:

• It runs on npm install, not at runtime. The malware installs a preinstall hook, so its code executes the moment you (or your CI runner) install dependencies — before your application ever starts, before any test runs. You don’t have to use the compromised package; you only have to install it.
• It rides your automation. By republishing with incremented patch versions, it slips straight through the ^ and ~ semver ranges in your package.json and any automated dependency-update bot that merges minor/patch bumps. Your tooling delivers the payload for it.
• It targets the crown jewels, not the workstation. The payload hunts and exfiltrates npm, GitHub, AWS, Kubernetes, and HashiCorp Vault credentials — “all the secrets it can find” — with a specific focus on CI/CD environments, then uses compromised GitHub credentials and GitHub Actions to infect more repositories. CI/CD is where the high-value, long-lived secrets live, which is exactly why the worm goes there.

It even modernised its command-and-control: ChainDrop uses EtherHiding, pulling instructions from the Ethereum blockchain. That makes the C&C censorship-resistant and very hard to take down — you can’t just seize a domain.

The uncomfortable truth about “we only use popular packages”

Popularity is not safety here — it’s the attack surface. Five hundred million weekly downloads means the blast radius is enormous because the packages are trusted and everywhere. And a committed package-lock.json only protects you until the next time something bumps a dependency: a new teammate runs npm update, a bot opens an auto-merge PR, a transitive dependency shifts. The defenses most teams lean on — lockfiles and “use well-known packages” — are necessary but nowhere near sufficient against a worm that weaponises the update mechanism itself.

How to actually defend against this

There is no single switch, but these controls, layered, meaningfully shrink your exposure:

1. Disable install scripts by default. The preinstall hook is the execution vector. Running npm install --ignore-scripts (or setting ignore-scripts=true in .npmrc) neutralises it. Some packages genuinely need build scripts, so allowlist those explicitly rather than leaving scripts on globally.
2. Pin exact versions and add a cooldown. Drop the ^/~ ranges for exact pins, commit your lockfile, and don’t adopt a version that was published minutes or hours ago. A quarantine window (via tooling like Socket, or a manual policy) would have caught ChainDrop, whose malicious versions were live for a short, frantic burst.
3. Treat CI/CD secrets as radioactive. Replace long-lived npm/GitHub/cloud tokens with short-lived, least-privilege credentials — OIDC federation instead of static keys wherever your platform supports it. A worm can only exfiltrate what the runner can see; give it as little as possible, for as short a time as possible.
4. Lock down maintainer accounts. This whole class of attack starts with one account takeover. Enforce phishing-resistant 2FA (hardware keys) on every account that can publish, and require npm publish provenance / signed attestations so consumers can verify a package was built from the source it claims.
5. Control and watch CI egress. Restrict outbound network access from build runners to what they actually need, and alert on anomalous outbound connections — exfiltration and blockchain-C&C lookups both have to leave your network somehow.

If you think you were exposed

Because the malicious versions were live before most teams knew, assume possible exposure if you installed from the affected namespaces in the window. The response, per the responders’ own guidance:

• Preserve evidence first — package tarballs, npm logs, CI logs, GitHub audit logs, and runner images — before you clean up.
• Rebuild CI runners and build machines from known-good images; don’t try to disinfect them in place.
• Revoke and rotate every credential those environments could touch — npm, GitHub, AWS, Kubernetes, Vault — not just the obvious ones.
• Audit your GitHub org for injected workflow files, unexpected Actions, and new package versions you didn’t publish.

For researchers and defenders

The highest-leverage lesson is where the fragility actually lives: the maintainer account and the publish pipeline, not the package code. A worm model means the economics have flipped — one credential compromise yields hundreds of poisoned packages and millions of downstream installs. That’s why provenance, hardware-backed 2FA on publishers, and registry-side anomaly detection (a maintainer suddenly pushing 2,000 versions in four hours is not subtle) are worth more than any amount of after-the-fact scanning. On the offensive-research side, install-time hooks, CI/CD token scoping, and the trust relationships between registries and source repos remain a rich, high-impact area.

The bottom line

ChainDrop is what modern supply-chain attacks look like: automated, self-propagating, and aimed squarely at the secrets in your build pipeline rather than your users. Lockfiles and package popularity won’t save you. Disable install scripts, pin with a cooldown, minimise and shorten CI credentials, and put hardware 2FA on anything that can publish. The registries will keep getting hit; the teams that treat their CI/CD pipeline as production infrastructure — and defend it like one — are the ones that come through clean.

---

Sources: SecurityWeek — Over 400 npm Packages Infected in ChainDrop Supply Chain Attack · Palo Alto Unit 42 — npm Threat Landscape · StepSecurity. Verify affected package names and versions against your own lockfiles and the registry before acting.