At 09:35 UTC on 4 August, keyv@6.0.0 went live on the npm registry carrying a malicious preinstall hook. Within roughly five minutes it was picked up by automated scanners - Socket's incident writeup puts average detection time at five minutes eighteen seconds - but by then the compromised maintainer token, belonging to a developer known as Jaredwray, had already been used to push malicious releases across the wider @keyv and cacheable families. Nine more packages in the cacheable ecosystem followed in a single burst between 10:09 and 10:14 UTC. Microsoft's Security Blog, which named the campaign ChainDrop, now tracks it across more than 400 packages from unrelated publishers, reached through the worm's own propagation rather than any further compromised credentials.
The part that makes this worse than a normal maintainer hack
A single hijacked maintainer account publishing a bad release is a known, survivable failure mode - rotate the token, yank the version, move on. ChainDrop is a different shape of problem because the payload doesn't stop at the account it started with. Once it runs, the malware queries the npm API for every package the stolen token or OIDC trusted-publishing relationship can reach, downloads each tarball, injects an identical malicious hook, bumps the patch version, and republishes - turning one compromised identity into a chain of newly infected packages with no further human error required at any step. Socket's team found the pattern repeating in bursts, packages several hops removed from the original keyv compromise showing up within the hour, entirely through automated propagation.
The payload itself, once running, is thorough. Per Microsoft's analysis, a first-stage loader script pulls down a Bun runtime with no checksum verification and executes a heavily obfuscated 728KB second stage that hunts for AWS, GCP, Azure and Vault credentials, Kubernetes service account tokens, SSH keys, shell history and GitHub Actions OIDC tokens, encrypts what it finds with AES-256-GCM, and exfiltrates it through attacker-controlled endpoints and, as a fallback, ordinary GitHub repositories. On infected machines it also drops a persistence mechanism - a LaunchAgent on macOS, a systemd unit on Linux - that watches the stolen GitHub token and waits for a remote command if that token gets revoked. Socket's report notes it even plants autostart hooks in .claude/settings.json and .vscode/tasks.json, so the payload can trigger the moment a developer opens an infected project in their editor or AI coding assistant.
Signed doesn't mean safe
The detail worth sitting with is what Socket's own report says plainly: "provenance attests build integrity, not source integrity." npm's signed provenance system did exactly what it was built to do - it confirmed that the package published matches what the build pipeline produced, using a legitimate OIDC token, through a legitimate CI run. What it can't confirm is that the source going into that build pipeline wasn't already trojanized before the build started. Every ChainDrop package carries a technically valid, cryptographically genuine attestation. If your dependency policy treats "signed" as a proxy for "trustworthy," this is the incident that shows why that shortcut fails - and it's the same structural gap we flagged when covering secure software supply chains and, on the model side, provenance and signing for AI model weights: a signature only ever proves who built the thing, never what went into it.
What to actually do about it
Microsoft's guidance, echoed by Socket and Aikido, is specific rather than generic. If your dependency tree touches keyv, any @keyv/* adapter, cacheable, flat-cache, file-entry-cache, cache-manager or cacheable-request, pin to a pre-6.0.0 version with an exact integrity hash rather than a caret range, and don't let automated update tooling near those namespaces until every maintainer account involved is confirmed clean. If you've already pulled a compromised version, the cleanup order matters: find and remove the persistence artefacts first - the gh-token-monitor script, LaunchAgent or systemd unit, and any .claude/settings.json or .vscode/tasks.json hooks - before you rotate a single credential, because a live persistence mechanism watching for a token revocation is exactly the thing that turns a clean rotation into a second compromise.
- Search your lockfiles now for keyv, any @keyv/* adapter, cacheable, flat-cache, file-entry-cache, cache-manager and cacheable-request at version 6.0.0 or any release published on or after 4 August 2026.
- If you find an affected version, remove persistence mechanisms first - check for unexpected LaunchAgents, systemd user units, and modified .claude/settings.json or .vscode/tasks.json files - before rotating any credentials.
- Rotate npm tokens, GitHub PATs, cloud provider keys and CI secrets from a clean host once persistence is confirmed removed, not before.
- Stop treating a valid signature or provenance attestation as evidence a package is safe - it only ever confirms the build matched its source, not that the source was clean going in.
- Enable npm's min-release-age feature where your workflow allows it, so a freshly published version has to survive a window of community scrutiny before your pipeline will pull it automatically.
ChainDrop will get patched, cleaned up and largely forgotten within a news cycle or two, the way most supply chain incidents do. The mechanism won't go away, because self-propagation through legitimate publishing credentials is a more efficient attack than compromising packages one at a time, and this is at least the second time this year a worm in this exact family - Wiz's report ties it to the earlier "Mini Shai-Hulud" campaigns - has used it. If your organisation needs help auditing dependency provenance or building a response plan that doesn't assume a signature is the end of the trust question, email sales@halfteck.com.