Skip to content
npmSupply Chaincredential-theftCI/CD

The npm Shai-Hulud worm: when valid provenance is no longer enough

3 min read
Share

What happened

On August 4, 2026, at roughly 09:00 UTC, an attacker who controlled the GitHub account behind keyv and cacheable pushed a credential-stealing payload directly to main and cut releases across the entire package family. A worm then propagated the compromise to nine unrelated organizations in under 30 minutes, moving at roughly one poisoned package per second. The final tally: 868 packages across 1,381 versions, covering over 2 billion combined monthly installs.

The blast radius

The attack started with keyv, a key-value storage library pulling 127 million weekly downloads. Because the same maintainer controls an entire ecosystem of caching utilities, the worm swept automatically through those namespaces. Flat-cache (565M monthly), file-entry-cache (557M monthly), and cacheable (29M monthly) were all caught in the same pass. These are not obscure packages. Flat-cache is a dependency of ESLint. File-entry-cache feeds ESLint's change-detection logic. If you run a JavaScript project, there is a high probability the poisoned code touched your CI pipeline.

The payload: Mini Shai-Hulud

The malware is a descendant of Mini Shai-Hulud, a credential-stealing toolkit that has circulated in underground markets. The attack uses a preinstall hook to download the Bun runtime and execute a 728 KB obfuscated stealer. Targets include .npmrc tokens, GitHub CLI tokens, AWS credentials, HashiCorp Vault tokens, Kubernetes configs, and crypto wallet files. The payload is optimized for CI runners and developer workstations, where these credential files coexist.

The provenance problem

Every poisoned tarball carries valid npm provenance signed by GitHub Actions. Every cryptographic check passes. This is not a case of an unsigned or suspicious package. The attestations are real, the signing pipeline is real, and the malware is also real. This is the second npm compromise in three months to ship malware with legitimate provenance attestations. The pattern is now established: provenance proves a package came from a specific workflow. It does not prove the person who triggered that workflow was acting legitimately, and it does not prove the source repository was clean at the time of the release.

What to do right now

Check your lockfiles for keyv, cacheable, flat-cache, and file-entry-cache. If any of those packages installed between August 4, 09:00 UTC and roughly 14:00 UTC, treat the environment as compromised. Rotate .npmrc tokens, GitHub tokens, AWS keys, Vault tokens, and any Kubernetes credentials that were present on the affected machine. Check npm audit logs for unexpected preinstall hook execution. Clean releases are now available across all affected packages. Update your lockfiles and re-install immediately.

Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you want to discuss supply chain security posture for your organization.