Shai-Hulud 'Here We Go Again' Hits keyv and cacheable - 868 npm Packages, Claude Code Hooks Planted

On August 4, 2026, an attacker compromised the GitHub account of the maintainer behind keyv and the cacheable package family and used it to publish a self-replicating credential stealer. The campaign brands itself "Shai-Hulud: Here We Go Again" - the third wave of the Shai-Hulud lineage - and it reached some of the most-installed packages in the npm registry: keyv, flat-cache, and file-entry-cache together account for well over a billion monthly installs, mostly as transitive dependencies nobody chose directly. Beyond credential theft, this wave did something new: it wrote itself into AI coding-agent configuration, planting a Claude Code SessionStart hook and a VS Code folderOpen task, and it read .claude/settings.json as a file worth stealing. This advisory covers what happened, why the AI-artifact layer is the part your dependency tooling will not clean up, and how Anomity surfaces and governs it.

What happened

The initial access was an account takeover, not a typosquat. The attacker gained control of the GitHub account of the maintainer who owns the keyv and cacheable ecosystem, pushed malicious code to the main branch, and published poisoned versions to npm. Because one maintainer stewards a cluster of foundational caching libraries, a single compromised identity reached keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cache-manager 7.2.10, and the @cacheable scope in one motion. These are dependencies of ESLint tooling, HTTP clients, and thousands of build pipelines - almost nobody installs them on purpose.

Execution came from an install-time hook. Each poisoned package added two files and a "preinstall": "node setup.mjs" entry to package.json, so the payload ran automatically during npm install. setup.mjs is an obfuscated dropper that downloads the Bun runtime (v1.3.13) from GitHub's release CDN and uses it to execute the real payload - a roughly 728 KB compiled Bun bundle shipped as Math_Symbol.js or math_init.js. Pulling its own runtime lets the payload sidestep the host Node environment entirely, and the Bun/1.3.13 user-agent became one of the cleaner network detections.

The payload is a broad-spectrum secret harvester. It collects npm tokens from ~/.npmrc (validating them against registry.npmjs.org/-/whoami before use), GitHub tokens in ghp_, gho_, and ghs_ forms plus OIDC JWTs from ~/.config/gh/hosts.yml, AWS credentials from ~/.aws/, the EC2 instance metadata service (IMDSv2 with IMDSv1 fallback), ECS container metadata, and Secrets Manager enumeration across regions, Kubernetes service-account tokens from /var/run/secrets/kubernetes.io/serviceaccount/ followed by API queries for namespace secrets, HashiCorp Vault tokens with full KV enumeration via /v1/sys/mounts, and Stripe and Slack keys by prefix. In CI it goes further, dumping GitHub Actions runner process memory to lift ACTIONS_ID_TOKEN_REQUEST_TOKEN and ACTIONS_ID_TOKEN_REQUEST_URL for OIDC token theft. A generic sweep of roughly 200 glob patterns covers .env*, private keys, SSH material, Terraform state, Docker configs, KeePass databases, VPN profiles - and IDE and agent settings, explicitly including .claude/settings.json.

Exfiltration is RSA-encrypted and uses GitHub itself as the dead drop: stolen bundles are pushed to public repositories whose description contains Shai-Hulud: Here We Go Again, of which roughly 1,300 existed at the time of reporting. Notably, the malware does not hardcode its fallback command-and-control domain. It resolves C2 at runtime by calling an Ethereum smart contract (StringListStore) via eth_call - infrastructure the operator can rotate without republishing the payload. The contract initially returned three domains and was later narrowed to npm-cache[.]com (registered 2026-05-22). The worm then replicates using the npm and GitHub tokens it just stole, which is what turned a handful of primary packages into secondary compromise across scopes including @onereach, @servicetitan, @or-sdk, @ornikar, @qlik, and @picsart.

Counts moved all day and still differ by tracker, which matters if you are scoping exposure: Aikido reported at least 868 packages across 1,381 versions exceeding 2 billion monthly installs, OX Security reported 440+ packages, and SafeDep revised from 353 poisoned versions to 1,684 versions across 420 package names. Treat every published figure as a floor, not a total. OX also reported a coercive dead man's switch - a payload branch threatening destruction if the stolen GitHub token is revoked, carrying the string IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients. Do not let that change the response: revoke the tokens anyway, and rebuild rather than negotiate with a threat string.

Why this is an agentic-endpoint risk

The part of this campaign that outlives the incident is the persistence it left in AI developer tooling. The worm wrote a SessionStart hook into .claude/settings.json pointing at .vscode/setup.mjs, and an Environment Setup task into .vscode/tasks.json with runOn: folderOpen pointing at .claude/setup.mjs - each config referencing the other's directory to look unremarkable in a diff. To be precise about the risk: neither fires on its own. VS Code blocks automatic tasks in an untrusted workspace, and Claude Code applies workspace trust to repository-supplied project settings, so both need a human to trust the folder. Those trust boundaries held, and they are the reason this was persistence rather than a second execution wave.

What they do not do is remove anything. The preinstall payload already ran before any trust prompt was relevant, and the planted hook stays on disk in every clone and every developer's working copy after the fact. This is where dependency remediation and AI-artifact remediation come apart: npm audit fix, a lockfile pin, or a version bump resolves the malicious package and leaves a .claude/settings.json hook sitting in a repository, waiting for someone to click *Trust* weeks later in a folder no scanner is watching. SCA tools read manifests and lockfiles. None of them inventory agent configuration, and this is the first Shai-Hulud wave to make that gap load-bearing.

The same blind spot explains why the theft went unnoticed. npm install running a preinstall script is ordinary developer activity to network monitoring; a Bun binary compiling and running looks like a toolchain to EDR; and secrets leave as an RSA-encrypted blob pushed to GitHub, which is indistinguishable from routine developer traffic to DLP. Hooks are one of the eight AI artifact types Anomity inventories per endpoint - alongside AI agents, MCP servers, extensions, skills, plugins, secrets, and CLIs - precisely because they are configuration that runs code on someone else's behalf, adopted bottom-up the way AI agents became the new shadow IT. This wave also confirms agent config is now a *target*, not just a vector: .claude/settings.json appeared in the harvester's own glob list. It shares its root cause with the sibling Shai-Hulud 2.0 and Mini Shai-Hulud waves, and with Miasma's binding.gyp variant: an install-time hook turned into credential theft that replicates.

How Anomity surfaces and governs it

First, inventory the artifact layer, not just the dependency tree. Anomity's unprivileged Endpoint Sensor runs on Windows, macOS, and Linux and inventories eight AI artifact types per endpoint, including hooks and the settings files that declare them. A planted SessionStart hook in .claude/settings.json, or a folderOpen task pointing at a dropped setup.mjs, is an inventoried artifact with a known first-seen time - so "which endpoints still carry agent config this worm wrote?" is one query rather than a fleet-wide hunt after your SCA report has already gone green. Anomity collects metadata only, and secrets are redacted on the endpoint, so the npm, GitHub, AWS, and Vault credentials this payload hunts are never centralized into a second target.

Second, decide at the hook. Where an agent exposes a control point - for example the PreToolUse event in Claude Code - Anomity evaluates each call against policy and returns allow, deny, or log before it runs. A session-start hook that spawns an unexpected process, reads a credential file, or pushes to a freshly created GitHub repository is denied at the boundary. That is what runtime governance provides against a payload whose whole design is to execute before review, and it is the control that still applies on the day someone clicks *Trust* on a repo cloned during this window.

Third, keep the record. Install events, config changes, and policy decisions land in a queryable 90-day audit trail, and findings route to SIEM, Slack, email, or Jira. For a campaign where the honest answer to "how many packages?" changed four times in a day, the useful question is narrower and answerable from your own fleet: which endpoints and pipelines ran an affected install, in what window, and what did their agents and hooks touch afterward. Anomity is SOC 2 Type II and complements EDR, DLP, network, and GRC tooling at the AI-artifact layer they were never built to see. See how it works.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Identify every endpoint, build agent, and CI pipeline that ran npm install on or around August 4, 2026, and check lockfiles for keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cache-manager 7.2.10, and any @cacheable version listed above - these arrive transitively, so search the resolved tree, not your direct dependencies.
• Treat any host that completed an affected install as compromised and rebuild it. The payload harvested before anyone could intervene, so cleaning the package is not remediation.
• Rotate npm and GitHub tokens first (they drive replication), then AWS keys and session tokens, Kubernetes service-account tokens, Vault tokens, Stripe and Slack keys, SSH keys, and anything in a .env reachable from an affected host. Enable 2FA and prefer short-lived and trusted-publishing credentials over long-lived PATs.
• Audit for AI and IDE persistence separately from dependency cleanup: search repositories and working copies for .claude/settings.json SessionStart hooks, .claude/setup.mjs, .vscode/tasks.json folderOpen tasks, and .vscode/setup.mjs. A version bump does not delete these.
• Hunt the IOCs in the table above - setup.mjs and Math_Symbol.js / math_init.js hashes, /tmp/bun-dl-*/, the Bun/1.3.13 user-agent, and traffic to npm-cache[.]com - and search GitHub for repositories described Shai-Hulud: Here We Go Again under your org's identities, then revoke their access.
• Review GitHub Actions workflow runs in the window for OIDC token requests and unexpected publishes, since runner memory was dumped for ACTIONS_ID_TOKEN_REQUEST_TOKEN, and check Secrets Manager and Vault access logs for enumeration.
• Set ignore-scripts for CI installs where feasible, pin dependencies with lockfile integrity verification, and adopt a cooldown that blocks package versions published within the last 24 hours - the control that would have blunted every Shai-Hulud wave to date.
• Inventory the hooks and agent configuration across your fleet using the hook and artifact inventory, and confirm agent tool calls are evaluated at a hook with allow/deny/log rather than trusted by default - see Claude Code permissions and hooks hardening and auditing Claude Code across a fleet.
• Run the credential-theft path of your AI agent incident response playbook rather than improvising, and extend the same review to other AI coding tools per securing AI coding agents and CLIs.

Shai-Hulud came back a third time because the primitive still works: one maintainer account, one install hook, and a registry that runs code before anyone reads it. What is new in this wave is the target. The worm read .claude/settings.json as a secret and wrote agent hooks as persistence, which puts AI coding tools on both sides of the attack - and leaves residue that dependency remediation will report as fixed. Rotate credentials and rebuild affected hosts, then inventory the hooks and agent configuration your endpoints actually carry. If you want the argument in playable form, we built the buried-hook problem into a turn-based artillery game - clear every worm you can see and you still lose the round. For the full picture of these campaigns and the controls that hold, see the pillar guide on AI supply-chain attacks: a defender's guide, and the related Trapdoor cross-ecosystem stealer and Cline npm token theft advisories. To see which endpoints in your fleet ran an affected install and what runtime governance would deny, request early access.