Audit Alert: Analyzing the Keyv Worm's IDE Persistence & npm Supply Chain Spread
Just finished reviewing the telemetry on the Keyv-linked supply chain attack that hit the registry on August 4. The scale is massive—SafeDep verified 353 poisoned versions, but Aikido’s reporting numbers closer to 868 impacted packages. What’s particularly nasty about this worm isn't just the initial keyv@6.0.0 infection vector, but how it propagated into the cacheable namespace and other orgs.
Beyond the standard dependency confusion, the payload is dropping persistence hooks directly into IDE configurations. We're seeing specific targeting for VS Code and Claude Code environments, effectively turning dev workstations into C2 beacons.
If you manage Node.js environments, I’d suggest auditing your package-lock. files immediately. Here is a quick script to check if you are pulling a compromised version of Keyv or its transitive dependencies:
#!/bin/bash
echo "Scanning for keyv@6.0.0 and known cacheable malicious versions..."
if grep -q '"keyv": "6.0.0"' package-lock.; then
echo "[ALERT] Poisoned keyv version detected!"
fi
# Check for the broader cacheable namespace spread
grep -E '("cacheable/[^"]+"|"@keyv/[^"]+")' package-lock. | while read line; do
# Add logic to cross-reference with the SafeDep report list here
echo "[WARN] Reviewing dependency: $line"
done
The spread across organizations suggests we need stricter CI/CD gates. Is anyone else seeing evidence of the IDE hooks attempting to exfiltrate tokens, or is the consensus that this is mostly dormant so far?
From a SOC perspective, we triggered on the VS Code extension anomalies late last night. The worm modifies the workspace settings to proxy extensions through a malicious source. We used this KQL query to hunt for affected dev boxes in our Sentinel environment:
DeviceFileEvents
| where FileName =~ "settings."
| whereFolderPath contains ".vscode"
| where InitiatedBy in ("node", "npm")
| project Timestamp, DeviceName, InitiatingProcessAccount
We found three machines with modified settings timestamps coinciding with `npm install` runs. Definitely recommend locking down write permissions to `.vscode` directories in your dev images.
This is exactly why we moved to lockfile-only installs in production (npm ci), but the dev environment risk is real. The IDE hook part is scary—if it's snagging Claude Code or AWS credentials from the VS Code integrated terminal, standard secrets scanning might miss it if the environment variables are set in the IDE's UI rather than .env.
We're temporarily blocking the cacheable org entirely in our Artifactory instance until the registry cleans up. It's a blunt instrument, but better than explaining a data breach.
I ran a quick pentest on a staging env that pulled the infected keyv version. The hook creates a symlink in the global node_modules directory to persist across project re-installs. The malware looks for ~/.config/Code/User/globalStorage to inject the payload.
If you're cleaning up, don't just rm -rf node_modules. You need to flush the global npm cache and check the IDE's global storage path. Standard AV isn't picking this up yet because it's JS-based and obfuscated.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access