Lead story
One Poisoned npm Package. 868 Infected Versions. The Keyv Worm Is the Supply Chain Nightmare in Motion.
It started with a single package. On 4 August, keyv@6.0.0 — a widely used JavaScript key-value storage library — shipped with a credential-stealing worm baked in. Within hours, the infection had spread far beyond Keyv's own namespace into hundreds of packages across dozens of organisations. By the time researchers finished counting, the numbers were staggering: SafeDep verified 353 poisoned versions across 79 package names; a broader sweep put the figure at 442 versions across 353 names; Aikido's monitoring eventually reported at least 868 affected packages in total.
This is how supply chain attacks compound. A maintainer or a build system publishes a new version of a popular package. The worm inside it reads the package's dependency graph and republishes poisoned versions of those packages too. Each new release fans out to the next ring of dependents. You don't need to target anyone specifically — the ecosystem does the targeting for you.
The payload here wasn't subtle. Infected packages planted hooks into Claude Code and VS Code, two of the most common AI-assisted developer environments in use right now. That's a deliberate choice: developer tooling is where credentials live, where API keys get pasted, where cloud environment variables sit in plaintext. If you can get code running inside a developer's editor, you've got access to everything they're building — and likely their production infrastructure too.
The incident echoes the Arch Linux maintainer compromise we covered Monday, but the mechanism is different and in some ways more alarming. The Arch attack required hijacking human accounts. This worm propagated autonomously through the package registry itself. No account needed to be compromised for each new infection — the malware did the spreading.
What makes this particularly messy is that npm's trust model is built on version pinning and integrity hashes, but those controls only protect you if the original publish was clean. Once a worm is inside the registry publishing legitimate-looking new versions, downstream consumers pulling latest or using loose version ranges get infected automatically. Lockfiles help — but only if your lockfile predates the poisoned release.
For defenders, the immediate priority is auditing package-lock.json and yarn.lock files for any Keyv or Cacheable dependency versions published on or after 4 August. Tools like npm audit may not flag these as vulnerabilities yet since the poisoning was in the published source, not a known CVE.
Australian exposure here is real. npm is the backbone of virtually every JavaScript project in Australia — from government digital services built on Node.js to the fintech and startup ecosystem that runs heavily on cloud-native JS stacks. Any team pulling packages from the npm registry without pinned, audited lockfiles should treat this as an active incident, not a theoretical risk. The ASD's Essential Eight specifically calls out patch management and application control, but supply chain integrity at the package-registry level remains a largely unaddressed gap in most organisations' frameworks.
The broader pattern is what should worry the industry. Worms that self-propagate through package registries are not new in theory — researchers have demonstrated the concept for years. But incidents of this scale, hitting this many packages this fast, are becoming operational reality. The question is whether the ecosystem — npm, GitHub, the open-source maintainer community — can respond fast enough to matter.
Watch for: how quickly npm's security team can pull the poisoned versions, whether any credentials harvested in the interim surface in the wild, and whether similar worm behaviour turns up in PyPI or RubyGems next.
