One compromised maintainer account, ten trojanized packages, two billion downloads a month — and the malware is specifically hunting for your Claude and Cursor configs.
At 9:35 UTC on August 4, someone using a stolen GitHub session published version 6.0.0 of keyv — a caching library Node developers pull in without thinking twice, the kind of dependency that's three layers deep in a project you didn't even know used it. Within the next 40 minutes, nine more packages went out under the same compromised account. Combined, those ten packages get pulled more than 2 billion times a month. Every one of them was now shipping malware.
How one GitHub account took down a chunk of the JavaScript ecosystem
keyv and cacheable aren't household names, but that's exactly the point. They're infrastructure — small, boring caching utilities that bigger frameworks quietly depend on. Jared Wray's GitHub account controlled both namespaces, and once an attacker got into it, they didn't need to trick anyone into installing something new. They just pushed to packages millions of projects already trusted implicitly. It's the same trust-by-default problem behind Gitea's file-read RCE bug from last month — self-hosted and self-published developer infrastructure is only ever as secure as the single weakest credential protecting it.
The four-hour window
09:00 UTC
Attacker pushes IDE persistence payloads to the keyv GitHub repository using the compromised maintainer account, per Wiz's incident timeline.
09:35–10:14 UTC
Ten trojanized package versions published to npm, including keyv@6.0.0, flat-cache@6.1.24, and file-entry-cache@11.1.7 — all carrying valid provenance signatures because they were pushed straight to main and released through GitHub Actions.
Within hours
Socket, Wiz, Snyk, Cloudsmith, and Aikido independently flag the compromise and begin publishing indicator-of-compromise lists as the worm self-propagates into downstream packages.
August 4–5
Propagation reaches over 400 npm packages, per Wiz, as the malware uses stolen npm tokens to trojanize packages the original compromised account never controlled in the first place.
What actually happens once it's on your machine
The infection runs in two stages, and the design tells you the attacker had time to plan this. Stage one is a small loader called setup.mjs, dropped in as a preinstall hook — meaning it runs before your own code, before your linter, before anything that might catch it. It quietly downloads a standalone Bun runtime with no signature check and hands off to stage two: a 728KB bundle called Math_Symbol.js that does the real work. Socket's incident writeup has the full technical breakdown and the complete list of affected packages.
The malware specifically hunts for AWS, GCP, Azure, and Kubernetes credentials — the keys to a company's entire cloud footprint. · Unsplash
The ten trojanized packages
keyv
Package
6.0.0
Malicious version
Compromised — published 09:35 UTC
cache-manager
Package
7.2.10
Malicious version
Compromised
cacheable-request
Package
13.0.20
Malicious version
Compromised
flat-cache
Package
6.1.24
Malicious version
Compromised
file-entry-cache
Package
11.1.7
Malicious version
Compromised
cacheable
Package
2.5.1
Malicious version
Compromised
@cacheable/utils
Package
2.5.1
Malicious version
Compromised
@cacheable/memory
Package
2.2.1
Malicious version
Compromised
@cacheable/node-cache
Package
3.1.2
Malicious version
Compromised
@cacheable/net
Package
2.1.1
Malicious version
Compromised — published 10:14 UTC
Package
Malicious version
Status
keyv
6.0.0
Compromised — published 09:35 UTC
cache-manager
7.2.10
Compromised
cacheable-request
13.0.20
Compromised
flat-cache
6.1.24
Compromised
file-entry-cache
11.1.7
Compromised
cacheable
2.5.1
Compromised
@cacheable/utils
2.5.1
Compromised
@cacheable/memory
2.2.1
Compromised
@cacheable/node-cache
3.1.2
Compromised
@cacheable/net
2.1.1
Compromised — published 10:14 UTC
Are you actually affected?
Check your lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) for any of the ten package versions above, installed on or after August 4, 2026.
2
If found, do NOT immediately rotate credentials yet — first hunt for and remove ~/.local/bin/gh-token-monitor.sh and any related hooks in .claude/settings.json or .vscode/tasks.json.
3
Pin every affected package to the specific version published immediately before August 4, 2026, not just 'latest'.
4
Only after removing the dead-man's switch, rotate npm tokens, GitHub tokens, cloud keys (AWS/GCP/Azure), and Vault/Kubernetes credentials.
5
Audit your own npm publishing history and GitHub org for packages or repos you didn't create.
This isn't a one-off. Researchers are calling this variant 'Mini' Shai-Hulud, and Chainguard's analysis traces it directly back to code shared with earlier worm campaigns this year, including the TeamPCP and @antv incidents. My honest read: npm's provenance signing — the mechanism that's supposed to prove a package build came from a clean GitHub Actions run — did nothing here, because the attacker never touched the build pipeline. They pushed straight to main with a valid, compromised account. That's not a supply-chain-security failure GitHub can patch; it's a maintainer-account-security failure, and there are hundreds of thousands of accounts just like Jared Wray's holding the keys to packages just as widely used.
The second-stage payload specifically targets AI coding assistant configuration files for Claude, Cursor, and Codex. · Unsplash
The malware's actual target list — Jenkins master keys, Argo CD, Harbor, /etc/shadow — reads like a checklist of exactly the CI/CD infrastructure already under fire this year. JetBrains' own build server, TeamCity, had its own unauthenticated remote code execution disclosed just weeks earlier, and combined with Langflow's unauthenticated RCE before that, the pattern is unmistakable: attackers are targeting the tools developers use to build software, not just the software they ship.
Is this the same as the Shai-Hulud worm from earlier in 2026?
Not exactly — researchers describe this payload as a 'Mini' Shai-Hulud variant, built from the same publicly available malware family but not identical code. It shares DNA with the TeamPCP and @antv campaigns rather than being a straight repeat.
Has a CVE been assigned?
No, not as of publication. This is being tracked through vendor security advisories (Socket, Wiz, Snyk, Cloudsmith) and shared IOC lists rather than a formal CVE record.
I only use keyv indirectly, through another framework. Should I worry?
Yes — that's exactly the risk. keyv and cache-manager sit deep in dependency trees for caching layers in much bigger frameworks. Audit your full lockfile, not just your direct dependencies.
What if I already rotated my credentials before removing the dead-man's switch?
Treat every rotated credential as still potentially exposed and rotate again after confirming the gh-token-monitor.sh persistence script is gone. Researchers haven't confirmed the switch fires in every case, but the design intent is clear enough that you shouldn't gamble on it.
Ten packages, one stolen GitHub session, two billion downloads a month — that's the entire story of why npm's trust model is under real strain in 2026. If your team ships anything in JavaScript or TypeScript, spend twenty minutes on the lockfile check above today, not after your next scheduled dependency audit. The packages you didn't choose are usually the ones that get you.
