Deep Dive: The Keyv npm Worm, IDE Hooks, and Cacheable Namespace Contamination
Just catching up on the fallout from August 4th regarding the keyv@6.0.0 incident. It looks like SafeDep's verification of 353 poisoned versions was just the tip of the iceberg—Aikido is reporting over 868 affected packages now. The fact that this went beyond the cacheable namespace into hundreds of other orgs is a nightmare scenario for supply chain security.
The specific MO here is insidious: it's not just crypto-mining; it's actively planting hooks in VS Code and Claude Code. This gives attackers persistence directly within the developer's IDE, potentially exfiltrating source code or API keys every time a file is saved.
If you haven't audited your package-lock. files yet, you need to. Look for any resolution to keyv@6.0.0 or suspicious updates in the @keyv or @cacheable scopes.
I whipped up a quick script to scan our CI/CD pipeline artifacts for the bad version range and common IDE hook locations:
#!/bin/bash
# Check for keyv@6.0.0 and suspicious .vscode/.claude directories
echo "Scanning for Keyv worm indicators..."
# Find node_modules with the specific package
grep -R '"keyv"' node_modules/*/package. 2>/dev/null | grep "6.0.0" && echo "[!] Vulnerable Keyv version found."
# Check for unexpected hooks in common IDE directories
if [ -d ".vscode" ]; then
find .vscode -name "*." -exec grep -l "api\.openai\|webhook\|exfil" {} \;
fi
if [ -d ".claude" ]; then
echo "[!] Claude Code config detected. Review contents manually."
fi
The propagation mechanism suggests a dependency confusion or typosquatting element that automated the spread. Is anyone seeing evidence that this worm attempts to modify package. in other projects to self-replicate, or is the spread purely via the npm registry dependency tree?
We deployed a hunting rule in Sentinel immediately after the news broke. We're looking for child processes spawning from VS Code or Node.js that reach out to unknown external IPs.
Here is the KQL we're using to catch the initial install:
DeviceProcessEvents
| where FileName in~ ("npm.exe", "node.exe")
| where ProcessCommandLine contains "keyv@6.0.0" or ProcessCommandLine contains "cacheable"
| where Timestamp > ago(48h)
| project DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
So far, we've blocked the install on 3 dev workstations via the proxy, but the persistence in VS Code is tricky to clean.
The persistence mechanism is the real story here. Hooking into Claude Code is next-gen; most orgs don't even monitor internal traffic from AI agents. I'd recommend checking your ~/.config/Code or ~/.claude directories for any settings. modifications that point to custom webhooks.
Also, verify your npmrc isn't pointing to a rogue registry. If the worm touched that, you'll keep getting reinfected even after cleaning node_modules.
cat ~/.npmrc | grep -E "registry|_authToken"
If you see anything other than `https://registry.npmjs.org/`, assume the creds are burned.
We locked down our internal registry to only allow specific scoped packages. It broke a few builds this morning, but it's better than dealing with a worm. For those cleaning up, don't just rm -rf node_modules. You need to wipe the global npm cache too, otherwise, the poisoned tarballs might still be local.
npm cache clean --force
rm -rf node_modules package-lock.
npm install
Double-check your CI runners as well—they often have stale caches.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access