A new npm supply chain campaign has crossed a line security teams have warned about for years. Instead of a human attacker manually publishing malicious updates package by package, a worm identified by Microsoft Threat Intelligence and tracked as ChainDrop used stolen maintainer credentials to republish itself automatically, spreading across more than 400 packages from unrelated publishers before most defenders had a name for it.
How the Worm Spread Itself
According to Microsoft’s August 4 writeup, ChainDrop began inside the keyv and cacheable namespaces after an npm maintainer’s GitHub account was compromised. From there the malware operated on a loop rather than a single payload drop: an npm preinstall lifecycle hook launched an obfuscated JavaScript payload running on the Bun runtime, the payload enumerated every package the compromised identity’s stolen tokens could reach, downloaded the latest tarball for each, injected malicious code, bumped the patch version, and republished it. A single compromised maintainer identity was enough to generate malicious releases across every package that identity could touch, no additional human attacker required after the initial credential theft.
Microsoft notes that the resulting malicious releases carried no corresponding source commits, pull requests, or tags in the packages’ repositories, a mismatch that is one of the clearest available signals for defenders scanning their own dependency trees for tampering.
What the Malware Took
Once running, ChainDrop harvested npm, GitHub, cloud, and infrastructure credentials: AWS access tokens, Kubernetes credentials, HashiCorp Vault secrets, GitHub Actions runner secrets and OIDC tokens, SSH keys, and shell histories. Stolen data was encrypted and sent to attacker-controlled domains, with GitHub repositories used as a fallback exfiltration channel when the primary domains were unreachable.
The malware also behaved differently depending on where it landed. On developer workstations it detached and persisted after the initial install. On CI/CD systems it stayed active specifically to reach workflow secrets and OIDC-scoped cloud permissions, the credentials most likely to unlock a production environment rather than just a laptop. Microsoft also found the malware injecting configuration changes into Claude and VS Code settings on infected machines, opening a secondary infection path through developer tooling itself.
Part of a Pattern, Not an Isolated Incident
ChainDrop is not the first worm to treat the npm registry as a self-propagating attack surface this year. As CyberTech reported when Amazon linked a string of popular npm package hijacks to a single North Korean crew, credential-driven takeovers of high-download packages have become a repeatable playbook rather than a one-off event. What distinguishes ChainDrop, per Microsoft’s analysis, is the automation: earlier campaigns generally required an attacker to manually push each malicious release, while ChainDrop’s republish cycle runs on its own once a single maintainer identity is compromised, a design that lets a single credential theft cascade across a publisher’s entire accessible package graph within hours.
What It Means for the Security Leader
For CISOs and application security teams, ChainDrop reframes two assumptions that shaped most software composition analysis programs to date. First, “this package hasn’t changed its maintainer or repository in years” is no longer a reliable trust signal on its own, since a stolen token lets an attacker publish under a legitimate, long standing identity with no visible ownership change. Second, CI/CD systems now need to be treated as a primary target, not an assumed trusted execution environment: ChainDrop specifically stayed resident in CI to harvest OIDC tokens and workflow secrets, credentials that grant direct access to cloud infrastructure with no further social engineering needed.
The combined download footprint of the affected packages, in the hundreds of millions of weekly downloads according to Microsoft, also means most organizations running a modern JavaScript stack should assume exposure is possible rather than wait for a vendor notification to check.
Why the Trust Signal Failed
Most dependency scanning today leans on metadata that ChainDrop specifically sidesteps: publisher reputation, download history, and time since the package’s last release. A package with five years of clean releases and a well-known maintainer name still passed every one of those checks the moment its publish credential was stolen, because the identity making the release was, technically, still the legitimate one. The signal Microsoft points to instead, a published version with no matching commit, pull request, or tag in the source repository, only shows up if a team is actually diffing registry contents against source history, a step most organizations do not automate today.
How to Tell if You Were Exposed
Because ChainDrop republished under existing, trusted package names rather than typosquatted lookalikes, the practical detection question is not “did we install something suspicious,” it is “did we install a routine patch-version bump of something we already trust, in the affected window, without a matching source change.” Teams should pull a full dependency tree (not just direct dependencies, since ChainDrop targeted widely-used utility packages like keyv and cacheable that sit deep in transitive chains), cross-reference installed versions against the compromised release list Microsoft has published, and check outbound network logs on build systems for connections to the exfiltration domains named in Microsoft’s advisory. Any CI/CD system that pulled an affected version should be treated as having leaked its OIDC tokens and workflow secrets, not merely as having run untrusted code.
What to Do Now
Microsoft’s guidance for affected and at risk organizations includes:
- Update the npm CLI to version 12 and enable the min release age feature, which delays trust in newly published package versions long enough for automated scanners and the community to flag malicious releases.
- Purge npm and yarn caches on any system that may have installed an affected package.
- Rotate all credentials, tokens, and secrets from a known clean host, treating anything touched by a CI/CD job in the affected window as compromised.
- Rebuild affected projects from known good baselines rather than patching in place, and rebuild CI/CD base images so cached, poisoned layers are not silently inherited into the next build.
- Review GitHub Actions OIDC token scopes and workflow approval settings to limit how much a single compromised job can reach.
Source: Microsoft Security Blog
