A self-propagating worm named ChainDrop moved through the npm registry in early August, compromising more than 400 packages across unrelated publishers and exfiltrating the credentials that enterprise CI/CD pipelines use to reach cloud infrastructure.
The attack started with stolen npm maintainer credentials. Once ChainDrop had a valid token, it enumerated every package that identity controlled, downloaded the latest release of each, inserted a malware bundle and a preinstall loader into the tarball, incremented the patch version, and republished the modified package. Any development team that ran npm install after the poisoned versions appeared in the registry had the preinstall hook execute before the installation completed. The hook collected npm tokens, GitHub tokens, AWS credentials, Kubernetes tokens, and HashiCorp Vault secrets from the CI/CD environment, then transmitted them over HTTPS to attacker-controlled infrastructure.
Microsoft documented the full attack chain on August 4, identifying major enterprise packages including keyv, flat-cache, and cache-manager among more than 400 compromised. For cloud-native organisations, the stolen credentials represent a direct path to production resources: an AWS credential reads S3 buckets, parameter stores, and Secrets Manager; a Kubernetes token enumerates cluster state and retrieves configuration secrets; a Vault token exposes database passwords and TLS certificates. None of the affected packages raised an error during installation. The worm returned a clean exit code.
Two things are worth pulling out of the reporting.
What scanners would have missed
Software composition analysis tools check dependency versions against CVE databases. ChainDrop has no CVE. It did not exploit a vulnerability in npm, in keyv, or in any CI/CD system. It abused npm's trust model by publishing tampered tarballs under legitimate package names at fresh patch versions that had never previously existed.
Four patterns explain the gap:
- Severity rankings that do not reflect the actual exploit path. A SCA scan of a package.json containing keyv at the poisoned version would return no known vulnerabilities. CVSS is undefined here, not because the risk is low, but because CVSS does not model supply chain integrity failures at the registry layer.
- Single-tool scope. SAST scans source code. DAST probes running applications. SCA checks dependency metadata against known-vulnerability databases. None of these inspect the npm registry to detect that a published version has been silently replaced since its prior release.
- Reachability analysis that stops at the application boundary. A tool that flagged a preinstall hook would not answer whether that hook was new to this version or whether it makes outbound connections to unfamiliar infrastructure. The question requires dynamic execution, not static inspection.
- A missing verification control. npm does not validate by default that a downloaded tarball matches a known-good hash from a prior build. The assumption that version X.Y.Z is the same artifact as last sprint is not enforced by any scanner in the standard SAST-DAST-SCA stack.
The failure is a build-time trust boundary that standard tooling is not designed to audit.
What Sekura would have shown
Phase 4 of Sekura's pipeline is exploit synthesis. The agent takes a hypothesis and produces a deterministic proof.
For a customer with keyv or flat-cache in their dependency graph, the exploit synthesis agent would start from a Phase 1 finding: the white-box SAST scan flagged that keyv at the affected patch version contains a preinstall script absent from the prior release, and that the script makes outbound network calls to an external endpoint. Phase 4 takes that finding and executes the tampered package in a sandboxed CI environment. The result is a working proof: which credential environment variables the preinstall hook captured, and where it transmitted them.
What we would not claim is that this analysis would have stopped ChainDrop from reaching the npm registry. The finding lives inside the customer's build pipeline: does your CI/CD environment verify tarball integrity before executing install hooks? ChainDrop turns that question into a concrete, demonstrable answer. The proof shows which tokens leave your environment and where they go, not a theoretical model of what an attacker could do.
The bigger pattern
This is a build-time trust attack. The category is not new, but the mechanism is.
Earlier supply chain compromises targeted single packages. ChainDrop targeted the maintainer identity layer: one stolen credential reaches every package that identity controls, across any publisher. A single token theft can cascade across hundreds of packages before any detection fires.
Enterprise security posture is mostly measured at the application layer. Organisations scan containers, audit APIs, and run SCA against dependencies. Fewer have a concrete answer to a simpler question: who verifies that npm install does not execute attacker code before the first line of your application runs? Build-time integrity is an assumed guarantee, not an enforced control. ChainDrop demonstrates what happens when that assumption is tested.
If you want to see what proof-first analysis of your build pipeline looks like, book a POC.