ChainDrop Turned Trusted npm Publishing into a Self-Propagating Attack
A new Shai-Hulud descendant spread through npm packages with legitimate-looking provenance. The incident shows why a trusted build path is not necessarily a trustworthy one.
Security researchers identified a fast-moving npm supply-chain campaign on 4 August and named it ChainDrop. The operation began with access to a GitHub account associated with the popular Keyv and Cacheable package families, then used package-publishing rights and compromised automation to push malicious releases.
Early incident totals varied as researchers counted package names, versions and later propagation at different moments. Aikido reported at least 868 packages across 1,381 versions, while other investigations published smaller confirmed sets. The affected package ecosystem was reported to receive more than two billion downloads per month. That download figure describes potential reach; it is not a count of infected organisations or devices.
The important fact is not the final number. It is that a compromise in a developer’s trusted publishing environment could spread rapidly into unrelated projects and build systems.
Installation became the execution point
The malicious packages used an npm preinstall lifecycle script. A routine dependency installation could therefore execute the payload before an application was built, tested or started.
Researchers reported that the malware downloaded the Bun JavaScript runtime and searched developer workstations and CI/CD runners for valuable secrets. Targets included npm and GitHub tokens, cloud credentials, Kubernetes configuration, environment files and other material that could provide access to repositories or production infrastructure.
Stolen publishing credentials then gave the worm a way to modify additional packages. This turned credential theft into propagation: one affected environment could create the next set of apparently legitimate releases.
Provenance did not mean benign
Some poisoned releases travelled through the projects’ real GitHub Actions workflows and carried valid provenance. The attestations could accurately show where and how an artefact was produced while saying nothing about whether an attacker had already taken control of that process.
That distinction matters. Provenance remains useful for detecting an unexpected build path, but it cannot compensate for a compromised maintainer account, workflow or signing authority. Organisations need controls around the build environment as well as verification of its output.
ChainDrop also follows the public release in May of source code associated with the Shai-Hulud malware family. Reusable offensive code shortens the distance between one campaign and its successors. Defenders should treat the August incident as a new wave requiring a fresh exposure check, not as a duplicate alert that can be dismissed because an earlier variant was investigated.
What development teams should do
Teams that installed npm dependencies during the incident window should investigate exact resolved versions rather than relying on today’s latest tag.
- Check lockfiles, package caches, build logs and software inventories against the current version-level lists published by incident responders.
- Isolate affected workstations and runners. Removing the dependency alone does not invalidate credentials already copied from the host.
- Follow the researchers’ current eradication guidance, then rotate npm, GitHub, cloud, CI/CD and deployment credentials from a known-clean system.
- Rebuild disposable runners and developer environments from trusted images when execution is confirmed or cannot be ruled out.
- Review repositories and package registries for unexpected commits, releases, workflow changes and new access tokens.
- Restrict lifecycle scripts where practical, apply a minimum release age and pin dependencies to reviewed versions.
- Prefer short-lived, narrowly scoped publishing credentials and keep production secrets out of package-install environments.
- Limit outbound network access from build jobs so that a successful install script has fewer routes for exfiltration.
The lasting lesson is that dependency security cannot stop at vulnerability scanning. Build identity, token scope, install-time execution and network egress all determine whether one poisoned package remains an incident or becomes a worm.
Sources and further reading
- Aikido Security: Keyv and related packages compromised in an npm supply-chain attack
- StepSecurity: ChainDrop npm worm analysis
- Socket: Keyv and Cacheable namespaces compromised
- TechRadar Pro: changing package counts and incident scope
- GitHub: disrupting supply-chain attacks on npm and GitHub Actions
The affected-package lists changed during the response. Confirm current indicators and remediation guidance before making an exposure decision.
