A newly identified worm named ChainDrop has quietly infected more than 400 packages on the npm registry, turning what should be routine software installs into an opportunity for large-scale credential theft, according to a report from Unit 42 shared with Cyber Security News.

How ChainDrop Spreads Itself

ChainDrop’s defining feature is that it doesn’t need a fresh phishing email or a fake website to spread — it propagates through the trust developers already place in the npm ecosystem. The worm compromises legitimate publishing accounts, and once it has access to one, a poisoned package runs automatically during installation, hunts for valuable access tokens on the machine, and then uses any stolen npm credentials to modify and republish additional packages under that same account. That cycle repeats automatically, meaning a single compromised developer or build server can end up infecting a much wider set of downstream packages without any further action from the attacker.

Unit 42 says the campaign has touched packages that are collectively downloaded hundreds of millions of times every week. Researchers identified 453 public repositories across five publishing accounts showing the worm’s data-theft pattern, though they note those accounts are possible rather than confirmed victims at this stage.

Hiding in Plain Sight

Rather than replacing a package outright, ChainDrop tucks itself inside an otherwise legitimate release. Infected versions add an install-time instruction, a small dropper, and an obfuscated payload while leaving the original, functional code untouched. That means a compromised package still behaves normally from a developer’s point of view — tests still pass, the library still works — which makes the infection far harder to catch through casual review.

Once installed, the malware can run silently on a developer’s workstation or inside a continuous integration job. From there it goes after:

• npm and GitHub authentication tokens
• Cloud provider credentials
• SSH keys and environment configuration files
• Developer-tool and AI-assisted coding tool settings

Notably, the malware also targets temporary secrets held in GitHub Actions runner memory — credentials that are never written to disk as a normal file, and that many teams assume are safe simply because they’re short-lived.

From One Package to Many

Once ChainDrop has usable publishing tokens, it identifies which additional packages the compromised account is authorized to update, injects its malicious components into them, bumps the patch version, and republishes — extending its own reach with each cycle. It also plants persistence inside project settings used by code editors and AI-assisted development tools, meaning simply opening an already-affected project in an editor can be enough to trigger the malware again, even after the initial install.

A Command Channel Built to Survive Takedowns

Beyond credential theft, ChainDrop can create new public repositories under a victim’s account, giving it an additional channel for exfiltrating stolen data. Its most unusual feature, though, is how it finds its command-and-control destination: through an Ethereum smart contract. That lets the operators change where the malware reports to without needing to update any of the infected packages directly — Unit 42 observed exactly this kind of infrastructure change take place on August 4.

That design complicates the usual “block and move on” response. An organization might successfully cut off one network route while missing a repository-based exfiltration channel, a poisoned lockfile, a cached package archive, or an already-built container image carrying the infected dependency.

What Defenders Should Do Now

Unit 42 recommends a multi-step response for any team that may have pulled in an affected package:

• Locate and remove affected package versions across all repositories, not just ones referenced by name
• Investigate developer machines and CI runners for signs of compromise before assuming a simple update fixes things
• Rotate npm, GitHub, cloud, SSH, and automation credentials on any confirmed-infected system
• Rebuild dependency lockfiles from trusted releases and clear old caches, mirrors, and package archives
• Move to short-lived, narrowly scoped credentials and single-use CI runners with strict outbound network rules for build jobs

Simply bumping a dependency to its “latest” tag isn’t enough — systems that already resolved a poisoned version during the exposure window need the same level of scrutiny as a direct credential-theft incident. Given how quickly ChainDrop can turn one compromised account into hundreds of infected packages, security teams are being urged to treat this less like a routine dependency bug and more like an active supply-chain breach.