Credential-Stealing Worm Spreads Across npm Packages
A worm seeded in a single npm package replicated into hundreds of others on August 4, 2026, with two security firms putting the damage count at different but alarming numbers.
Key points
- A credential-stealing worm first appeared in keyv@6.0.0 before spreading beyond the Keyv and Cacheable namespaces on August 4, 2026.
- SafeDep verified 353 poisoned versions across 79 package names, and put the wider footprint at 442 versions across 353 names.
- Aikido reported the worm reached at least 868 packages in total.
What happened with the npm packages?
On August 4, 2026, a credential-stealing worm seeded inside keyv@6.0.0 broke out of the Keyv and Cacheable namespaces and spread across packages belonging to multiple organisations. SafeDep, which monitors software supply chains, verified 353 poisoned versions across 79 package names. Its broader scan put the footprint at 442 versions across 353 names. Aikido, a separate security firm, later counted at least 868 affected packages. The gap between those figures reflects how quickly the worm moved and how differently the two firms drew their scope boundaries. This is at least the fourth npm-ecosystem story we've tracked in the past 90 days: our story on fake Alibaba developer tools, filed the day before this worm went wide, showed the same registry being used as a delivery mechanism for remote-access malware.
Should developers be worried?
Yes, and the specific mechanism matters here. A worm that self-replicates through package dependencies doesn't need a developer to install a rogue package directly. If one upstream dependency is poisoned, everything downstream that resolves to it inherits the problem. Any project that pulled one of these packages during the window of infection should treat its credentials as potentially exposed and rotate them. Audit your lockfiles, pin versions, and check published package hashes against what you actually received.
How can developers protect their projects?
Self-replicating malware in a public registry is a harder problem than a single booby-trapped package, and the tooling that catches the latter isn't always set up to catch the former. SafeDep and Aikido both spotted this through registry-level monitoring, which most individual development teams don't run themselves. The practical answer is to integrate a software composition analysis tool, one that compares installed package contents against known-good checksums, into your build pipeline. Pinned lockfiles slow the spread; reproducible builds make it visible. The worm's presence in packages tied to Claude Code and VS Code hooks is a particular concern: tooling that developers run with elevated trust and broad filesystem access is exactly where credential theft does the most damage.
