ChainDrop Worm: Self-Spreading Malware Infects 400+ npm Packages

Published on 16 August 2026

On 4 August 2026, a single, seemingly harmless command was enough to steal credentials from numerous software projects: npm install. In Node.js projects, this command downloads the required program libraries – and it was precisely this installation process that was turned into a weapon. A self-propagating piece of malware called ChainDrop had embedded itself in more than 400 npm packages. Anyone who installed one of the infected packages ran malicious code without lifting a finger – no application launch, no import, no click required.

What made it special and dangerous: ChainDrop didn't just steal passwords and keys, it used stolen publishing rights to copy itself into further packages. A worm in the truest sense. Security researchers at Snyk make it clear:

„This is an active software supply chain incident, not a proof of concept.“ – Snyk Security Research (Liran Tal and Lion Kontorer)

In plain terms: this is a real, actively exploited attack on the software supply chain – not a theoretical lab scenario. This article explains in accessible terms what happened, whether your company could be affected, and what concrete steps to take now.

What happened?

npm is the world's largest repository for JavaScript software building blocks. Almost every modern website, every online shop and every content management system built on JavaScript or Node.js draws indirectly on npm packages when being built or run – often on hundreds at once.

On 4 August 2026, this trust relationship was exploited. According to Microsoft Threat Intelligence, attackers first gained control over popular packages around the keyv library and the so-called cacheable family via stolen credentials of a package maintainer. Snyk independently confirmed eleven malicious releases at first. Microsoft documented a total of more than 400 compromised packages across several mutually independent publishers.

The timeline was breakneck: at 09:35 UTC the tampered version keyv@6.0.0 appeared. Between 10:09 and 10:28 UTC, ten more poisoned versions followed. A snapshot by StepSecurity from the same day already counted 444 packages and 2,212 poisoned versions. Two days later, the Cyber Security Agency of Singapore (CSA) spoke of more than 1,300 affected package versions.

Important: these figures are not victim counts

A common misunderstanding: the figures cited describe the reach within the npm ecosystem – that is, how many packages were tampered with and how often they are typically downloaded. They say nothing about how many companies, systems or data records were actually compromised. There is no confirmed public figure for affected organisations or personal data records. Claims such as "two billion affected" are simply false – the two billion refers to monthly downloads, not victims.

The technical background – explained plainly

Why was mere installation enough?

npm packages are allowed to include so-called lifecycle scripts – small programs that run automatically, for instance directly during installation. One such script is called preinstall. The tampered packages added exactly this entry: "preinstall": "node setup.mjs".

This means: as soon as someone installed the package, the file setup.mjs started automatically – a heavily obfuscated loader program. The user had neither to include the library in their code nor to launch the application. The mere installation command was enough. The obfuscated program then downloaded a second-stage payload based on the Bun runtime environment.

What did the malware do?

ChainDrop deliberately distinguished between developers' machines and automated build systems (so-called CI/CD runners that build and roll out code). It searched files, environment variables and command-line tools for credentials for:

• npm (publishing rights for packages)
• GitHub (source code management)
• cloud services such as AWS
• Kubernetes (container orchestration)
• HashiCorp Vault (secrets vault)

The collected data was packaged, compressed and, using the strong AES-256-GCM method, encrypted before being transmitted to attacker infrastructure – including to the domain npm-cache[.]com.

The worm mechanism

If ChainDrop found an npm token with write permission, things got really dangerous. Microsoft researchers sum it up like this:

„The payload’s most significant capability is automated propagation.“ – Microsoft Security Research

So the most important capability was automatic propagation: the malware determined which further packages the victim was allowed to publish, downloaded them, injected its preinstall hook and the payload, bumped the version number and republished the tampered packages. In this way, the attack propagated on its own.

Why "verified provenance" wasn't enough

A particularly sobering finding: some tampered releases carried valid provenance attestations (so-called provenance via GitHub Actions). That sounds trustworthy, but it is deceptive. StepSecurity puts it aptly:

„Provenance proves which commit was built. It cannot prove the commit was authorized.“ – StepSecurity / Sai Likhith

In essence: provenance only proves which code state was built – not whether that code was authorised or harmless. If the regular build process is already processing compromised code, the provenance looks clean even though it is not.

Who is affected?

For German small and medium-sized enterprises, the rule is: anyone using Node.js/npm is affected – directly or via a service provider. This applies in particular to:

• websites, shops or headless CMS with a JavaScript-based build process
• developer laptops and automated build and deploy systems (CI/CD runners)
• agency projects in which a service provider handles the build
• container images (Docker) and package caches (proxies, artifact repositories)

Developer machines and build servers are especially critical, because they often hold credentials for GitHub, cloud, databases and production systems – exactly the loot ChainDrop was after.

Some reassurance – but with a caveat: a purely static website or a classic WordPress/PHP site without an npm build is not directly affected via this installation route. Nevertheless, an indirect risk can exist if your deployment or an involved service provider uses npm.

How to check whether you are affected

1. Take stock: First clarify whether npm/Node.js is involved at all – in source code, build configurations, Dockerfiles, hosting and agency projects, and in package proxies.
2. Check lockfiles, not just package.json: A lockfile records the exact installed versions. A quick overview can be obtained with:
   npm ls keyv flat-cache file-entry-cache cacheable-request cacheable @cacheable/utils cache-manager @cacheable/net @cacheable/node-cache @cacheable/memory ecto --all
3. Cross-check confirmed malicious versions: Snyk confirmed, among others, keyv@6.0.0, @cacheable/net@2.1.1, @cacheable/node-cache@3.1.2, cacheable@2.5.1, flat-cache@6.1.24, @cacheable/memory@2.2.1, cacheable-request@13.0.20, file-entry-cache@11.1.6, @cacheable/utils@2.5.1, cache-manager@7.2.10 and ecto@5.0.1. Also check transitive (indirect) dependencies, CI caches and already-built containers.
4. Read installed manifests – without executing package code: Search node_modules/**/package.json for "preinstall": "node setup.mjs" as well as for the files setup.mjs, Math_Symbol.js or math_init.js. Compare their SHA-256 checksums with the published indicators, e.g. 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668 for setup.mjs.
5. Check telemetry: Search process and CI logs for node setup.mjs, a subsequently launched bun process, temporary directories bun-dl-* or connections to known domains. Microsoft provides concrete search queries for Defender XDR.
6. Look for persistence: Check for ~/.local/bin/gh-token-monitor.sh, unexpected .claude/settings.json, .vscode/tasks.json as well as new, unexplained releases and workflow changes in GitHub.
7. Establish timing: Use the logs to determine when installation took place and whether lifecycle scripts were active. A mere lockfile hit without script execution is a different matter from actual execution. Preserve logs as evidence before any clean-up.

Remember: an entry in the lockfile does not yet prove that malicious code was executed – and conversely, the absence of an alert is no acquittal.

What you need to do now

1. Isolate, but preserve evidence: On a confirmed hit or a credible execution indicator, isolate the affected machine or CI runner – but first secure logs, process data and timestamps. Treat the system as potentially compromised.
2. Remove persistence first: Disable the gh-token-monitor and other persistence mechanisms. Caution: Snyk warns that revoking an observed GitHub token can trigger a stored action. Clean-up ideally belongs in the hands of an incident response team.
3. Rotate all secrets – from a clean system: npm tokens, GitHub access, cloud credentials, SSH keys, Kubernetes configurations, Vault and database access. Rotation on a still-suspect machine is not enough.
4. Force clean versions and rebuild: Snyk names as hook-free predecessors, among others, keyv@5.6.0, flat-cache@6.1.23, file-entry-cache@11.1.5, cacheable-request@13.0.19, cacheable@2.5.0, cache-manager@7.2.9 and ecto@5.0.0. The documented procedure: npm install --package-lock-only --ignore-scripts, then rm -rf node_modules, npm cache clean --force and npm ci --ignore-scripts. Check compatibility beforehand.
5. Clean caches and images: Remove compromised packages from npm/yarn caches, private registries, CI caches and container base images. Rebuild runners and golden images from a verified, clean state.
6. Check audit trails: npm releases, GitHub commits and workflows, cloud and secret store access, and outbound connections. Use the published indicators as a supplement – not as the sole proof.
7. Harden permanently: Deploy npm CLI 12 with a versioned allowScripts allowlist. This version was released on 8 July 2026 and blocks lifecycle scripts from dependencies by default. In CI, always install without lifecycle scripts, use exact versions and lockfiles, grant tokens minimally, avoid 2FA bypasses and enable phishing-resistant multi-factor authentication.

Important: npm 12 is a preventive protective feature, not a ChainDrop-specific patch. It does not replace a forensic investigation of an installation process that has already happened. There is no single vendor patch for a CVE here – ChainDrop is a compromised supply chain, not a classic software vulnerability.

Context and GDPR

ChainDrop is not automatically a reportable data breach. The incident only becomes a personal data breach within the meaning of the GDPR if a compromised developer PC or CI runner was able to reach personal data, database access or secrets granting access to personal data.

The LDI NRW sums up the threshold clearly: every breach must be documented internally. If there is likely to be more than a low risk to the rights and freedoms of natural persons, the competent supervisory authority must be informed without undue delay and, where feasible, within 72 hours (Art. 33 GDPR). Where a high risk is likely, the data subjects must also be notified (Art. 34). A processor – such as your agency – must inform the controller without undue delay.

Art. 32 GDPR requires appropriate technical and organisational measures to secure the processing. Infringements of the obligations listed in Art. 83(4) can be sanctioned with fines of up to EUR 10 million or 2% of annual global turnover – whichever is higher. The actual amount always depends on the individual case. That supervisory authorities take Art. 32 seriously is shown by an earlier case: in 2020, the LfDI Baden-Württemberg imposed a fine of EUR 1.24 million on AOK Baden-Württemberg for inadequate measures. Its then head, Dr Stefan Brink, stressed:

„Datensicherheit ist eine Daueraufgabe. Technische und organisatorische Maßnahmen sind regelmäßig den tatsächlichen Verhältnissen anzupassen, um auf Dauer ein angemessenes Schutzniveau sicherzustellen.“

The AOK case is not a supply-chain case and no forecast for ChainDrop – but it does demonstrate the supervisory authority's expectations: documented decision-making processes, prompt containment, robust risk analysis and demonstrable remediation. Where there is a concrete suspicion, data protection officers and specialist legal advice should be brought in early.

Conclusion

ChainDrop is a case study in modern attacks: it was not a programming error but the chain of trust itself that was abused. Merely installing a package was enough to steal credentials – and stolen publishing rights turned a single incident into a self-propagating worm. The CSA Singapore classifies the incident as an active supply-chain attack; the exploitation is real and in the wild.

For your company this means: if npm/Node.js is involved anywhere in your build, deployment or at a service provider, the check is a high priority – and on a concrete version match, act immediately. A purely static or PHP site without npm is not directly affected via this route, but do check the indirect risk via your service providers.

And keep a cool head: the figures circulating describe reach, not victims. A factual, well-documented review of your own environment is worth more than any headline. That is exactly where we support you – get in touch if you would like your build pipeline and your npm dependencies securely reviewed.