BIP America News & Media Platform

collapse
Home / Daily News Analysis / ChainDrop: the npm worm that faked being legitimate

ChainDrop: the npm worm that faked being legitimate

Aug 05, 2026  Twila Rosenbaum  12 views
ChainDrop: the npm worm that faked being legitimate

A self-spreading worm tore through the npm package registry on Tuesday, poisoning hundreds of packages that huge swathes of the software world quietly rely on. Researchers named it ChainDrop. It is a bigger, meaner descendant of the smaller Shai-Hulud attack that hit the registry earlier this summer.

The worm began by hijacking the GitHub account of the developer behind keyv, a caching library pulled in about 150 million times a week. From there it spread to sibling packages, then to hundreds of others. Within two hours it had reached corporate names like Deliveroo, Qlik, Picsart and ServiceTitan. The affected packages draw billions of downloads a month, and the attack ranks among the largest ever seen on npm.

The exact tally kept climbing, and researchers’ counts differed. The organisations tracking it included BleepingComputer, Aikido and StepSecurity. They put the damage at hundreds of packages and well over 1,300 poisoned versions. npm has been hit before. This was among the largest.

It weaponised the industry’s own trust signals

What made ChainDrop dangerous was not just the malware itself, but the way it was distributed. The attacker did not steal a token and upload the malware by hand. Instead, he pushed poisoned code into the projects’ main branches and then let each project’s own automated release pipeline publish it.

The malware shipped through legitimate GitHub Actions workflows. Every poisoned version carried valid provenance, the cryptographic attestation meant to vouch for a clean build. Any tool that checks for provenance waved the packages straight through. As StepSecurity noted, provenance proves which commit was built, but it cannot prove that the commit was authorised.

The rest ran on autopilot. Each poisoned package added a preinstall hook, so a plain npm install quietly ran a dropper. The dropper downloaded the real Bun runtime from GitHub and used it to launch a heavily obfuscated credential-stealer. Every network request pointed at github.com, so nothing looked out of place to monitoring systems that allowlist GitHub.

This technique is particularly troubling for the open-source ecosystem because package managers and security scanners increasingly rely on provenance as a sign of safety. If attackers can compromise a maintainer account and push malicious code through official CI/CD pipelines, the attestation becomes meaningless. The same trust signals that protect users are turned against them.

ChainDrop is also a reminder that maintainer accounts are high-value targets. The keyv developer’s GitHub account was hijacked, and from there the attacker gained access to a library that is embedded in thousands of projects. Many developers assume that popular packages are maintained by organisations with strong security, but in practice many critical libraries are maintained by one or two people. A single compromised account can cascade into a registry-wide incident.

What it takes, and where it hides

The payload is a vacuum. It harvested npm and GitHub tokens, plus cloud secrets from AWS, Kubernetes and Vault. It grabbed SSH and private keys, and database and Slack credentials. On GitHub Actions runners it dumped the machine’s memory to steal the job’s secrets. New this time, it also hunted AI-tool credentials, reading config files for Claude Code, Cursor, Codex, OpenAI and Gemini.

The inclusion of AI coding tools marks an evolution in credential theft. Developers are increasingly storing API keys and authentication tokens in configuration files for AI assistants and code editors. Those tools are often granted broad access to repositories, cloud accounts and third-party services. By targeting them, ChainDrop broadens the blast radius of a single stolen laptop or build server.

Then the malware spread itself. Using the npm tokens it stole, it repackaged and republished trojanised versions of every package each victim could publish. One infected laptop or build server seeded the next. That loop is what makes it a worm rather than a one-off breach. The more credentials it collected, the more packages it could poison, and the more victims it could reach.

Two touches make it hard to kill. First, it resolves its command server from a smart contract on the Ethereum blockchain. There is no fixed address to block or seize. The attacker can update the contract to point to a new server at any time, and each infected machine will follow the new address without needing a malware update. This is a growing tactic among advanced adversaries because it decentralises command-and-control and resists takedown.

Second, it plants persistence in AI coding tools. It adds a Claude Code start-up hook and a VS Code task that runs when a folder opens. Simply opening an infected repository in those tools re-runs the malware, with no install required. This is a significant departure from traditional supply-chain attacks, which usually require an npm install or a build step to activate. ChainDrop can survive on a developer’s machine even if no package is ever installed, as long as the developer opens a poisoned repository in an affected editor.

Cleanup and advice

npm began pulling the poisoned versions within about two hours, and keyv reverted to a safe release. The researchers’ advice is blunt. Anyone who installed an affected version should treat the machine as compromised and rotate every credential. But remove the malware’s token watcher first. It fires an attacker payload the moment you revoke a stolen token.

That final warning underscores how careful cleanup must be. Many security playbooks tell victims to rotate credentials immediately, but ChainDrop anticipated that response. It monitors the token store and triggers a second-stage payload when it detects a revocation attempt. Incident responders therefore need to isolate the machine, locate and remove the watcher, and only then rotate credentials.

The cheap fix that would have stopped most of this is dull. Install with scripts disabled, and wait a few days before trusting a brand-new version. It is the lesson the ecosystem keeps relearning, at a bigger scale each time.

The npm registry has been hit by a long line of supply-chain attacks, from the event-stream incident to the ua-parser-js compromise and the earlier Shai-Hulud campaign. Each one exploited the same underlying weakness: a package with a large implicit trust footprint and a small security perimeter. ChainDrop stands out not because it invented a new vulnerability, but because it automated the abuse of the ecosystem’s own publishing pipelines and shifted the attacker’s command-and-control to a blockchain.

For maintainers, the immediate takeaways are to enable two-factor authentication, restrict write access to GitHub repositories, review workflow changes carefully, and avoid letting release pipelines auto-publish new versions without human approval. For users, the safest practice is to treat every dependency update as a potential attack vector. Installing with --ignore-scripts reduces the risk of preinstall and postinstall hooks, but it is not a complete guarantee. Monitoring for unexpected network connections and auditing the dependency tree still matter.

The incident is not over, at least for the teams that have to clean it up. The full extent of the compromise may not be known for weeks, and the stolen credentials could be used in future attacks. ChainDrop is a reminder that the software supply chain is only as strong as the weakest maintainer account, and that trust, when automated, can be weaponised.


Source: TNW | Data-security News


Share:

Your experience on this site will be improved by allowing cookies Cookie Policy