Keyv npm Supply Chain Attack: Shai-Hulud Hits 2B Installs

If you ran npm install today, stop and read this. On August 4, 2026, attackers compromised the GitHub account of the maintainer behind the Keyv npm package ecosystem — a caching library with 604 million monthly downloads — and injected credential-stealing worm malware across 11 directly owned packages. By 13:37 CEST the same day, the worm had self-propagated to at least 868 additional packages spanning 1,381 versions, with combined monthly installs exceeding 2 billion. This is one of the largest npm supply chain attacks ever recorded, and it is still active as of this writing. According to Aikido Security’s disclosure, the compromised package list continues to grow.

A Worm, Not Just an Attack

Most supply chain attacks are static: compromise a package, wait for downloads, collect credentials. However, Shai-Hulud is different. The malicious versions — including keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, and cacheable-request 13.0.20 — each included a modified package.json with a preinstall hook that automatically ran node setup.mjs on install. That obfuscated dropper downloaded the Bun JavaScript runtime from GitHub and used it to execute the real payload: a 728 KB credential harvester named Math_Symbol.js.

Moreover, the worm mechanic is what makes this attack exceptional. After sweeping the system for credentials, the malware used stolen npm tokens to publish malicious updates to packages owned by other maintainers — spreading the attack sideways across the npm registry. For example, flat-cache and file-entry-cache are direct dependencies of ESLint. Keyv itself is embedded in countless frameworks and build tools. The attacker chose the right entry point, and the cascade followed automatically.

Everything Gets Stolen

The 728 KB payload does not target one type of credential. Instead, it scans roughly 200 file glob patterns and targets nearly everything on the system. The Wiz security analysis documents the full scope: npm tokens from ~/.npmrc, GitHub tokens (classic PATs, OAuth, and App tokens), AWS credentials from ~/.aws/credentials, environment variables, EC2 instance metadata, and AWS Secrets Manager across all regions. On Kubernetes, it queries the API directly to retrieve namespace secrets. Additionally, HashiCorp Vault tokens, SSH private keys, Terraform state files, Docker credentials, and KeePass databases are all in scope.

Two details stand out. First, on GitHub Actions runners the malware reads runner process memory directly to extract the entire secret store, including OIDC tokens used for publishing. Second — and this is new terrain — AI configuration files are explicitly targeted. LLM API keys are now part of the standard attacker harvest. Consequently, all stolen data is encrypted and exfiltrated to a GitHub repository whose description reads: “Shai-Hulud: Here We Go Again.” The attacker is not being subtle about the fact that this is an ongoing campaign.

Related: LLM Slop CVEs: 54 Fake Vulnerabilities Hit NVD — Act Now

Why npm Provenance Signing Did Not Help

Here is the part that should unsettle anyone who thought npm provenance signing was a solved problem. The poisoned versions were published with valid GitHub Actions provenance signatures. npm’s provenance system correctly identified that these packages came from the legitimate repository — because they did. The attacker had pushed directly to the legitimate repository. In other words, provenance proves origin. It says nothing about whether the origin was clean.

Furthermore, as The Hacker News reports, the malware also planted persistence hooks targeting developer machines: a Claude Code SessionStart hook in .claude/settings.json and a VS Code Environment Setup task in .vscode/tasks.json with runOn: folderOpen. These do not fire automatically in default configurations. Nevertheless, they survive credential rotation — meaning a compromised developer machine may re-run the malware the next time a workspace is approved. Therefore, rotating credentials is necessary but not sufficient if the machine itself is still compromised.

What to Do Right Now

If there is any chance your environment installed or updated npm packages today, treat the system as compromised and act accordingly. This is not a situation where monitoring and waiting is appropriate.

• Check your installed versions: keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, and cache-manager 7.2.10 are the malicious versions. Downgrade or remove immediately.
• Scan for IOC artifacts: Look for /tmp/bun-dl-*/ directories and Math_Symbol.js in node_modules. Check logs for user-agent Bun/1.3.13 and connections to npm-cache[.]com.
• Rotate all credentials immediately: npm tokens, GitHub PATs, AWS access keys, Kubernetes service account tokens. Do not wait to determine whether you were affected — assume you were.
• Audit CI/CD environments: Build pipelines that install npm packages are extremely high-risk. Rotate all credentials associated with build systems and review runner logs for the IOCs above.
• Check IDE configuration directories: Review .claude/settings.json and .vscode/tasks.json for unexpected hooks, particularly SessionStart entries or folderOpen tasks you did not add.

Key Takeaways

• One compromised GitHub account enabled a worm that reached 868+ npm packages and 2B+ monthly installs within hours — this is the supply chain attack model at unprecedented scale and speed
• npm provenance signing provides false confidence when the source repository itself is compromised; maintainer account security is now the effective supply chain perimeter
• The Shai-Hulud campaign is ongoing and escalating — it previously hit PyPI in April 2025; “Here We Go Again” is a statement of intent, not irony
• AI tooling is now explicitly targeted: LLM API keys and Claude Code configuration directories are active parts of the attacker harvest