Check a lockfile
Runs in your browser. Nothing is uploaded, stored or logged.
Revoking the token is a trigger. Remove the watcher first.
The payload installs a monitor that fires an attacker payload when the stolen GitHub token is revoked. Clean the host before you rotate, not after, and rotate from a machine that never ran the install.
What to do, in order
Find it
Search package-lock.json, yarn.lock and pnpm-lock.yaml for the affected versions, including transitive dependencies. Check CI caches and artifact repositories too, not just repos.
Clean the host before rotating
Remove the payload artifacts and the token watcher first. Rotating while the watcher is live triggers it.
Rotate from a clean machine
npm tokens, GitHub credentials, cloud keys, SSH keys, Kubernetes secrets, Vault values, and every CI secret that was in scope for the affected job.
Check what you publish
If you maintain npm packages, audit your own registry versions for releases you did not publish. That is how the worm moved.
Pin and rebuild
Pin known-good versions, purge npm and yarn caches on affected machines and build hosts, then rebuild from a known-good baseline and confirm the artifacts are absent.
The eleven carriers
These shipped the loader and the full 727,680-byte payload directly. Everything else in the affected set was republished automatically by the worm. All eleven have since been reverted to safe versions, but anything that installed them in the window is still exposed.
| Package | Poisoned version | Published | Weekly downloads |
|---|---|---|---|
| keyv | 6.0.0 | 09:35:00 | 153,717,238 |
| flat-cache | 6.1.24 | 10:10:55 | 149,868,983 |
| file-entry-cache | 11.1.6 | 10:13:02 | 147,558,494 |
| cacheable-request | 13.0.20 | 10:11:24 | 33,963,726 |
| @cacheable/utils | 2.5.1 | 10:14:21 | 8,713,375 |
| cacheable | 2.5.1 | 10:10:44 | 7,877,004 |
| @cacheable/memory | 2.2.1 | 10:11:29 | 7,176,667 |
| cache-manager | 7.2.10 | 10:14:41 | 4,281,731 |
| @cacheable/node-cache | 3.1.2 | 10:10:34 | 1,555,151 |
| ecto | 5.0.1 | 10:28:01 | 1,293 |
| @cacheable/net | 2.1.1 | 10:09:44 | 975 |
How one patch release became 444
- 09:02
Poisoned commit lands in jaredwray/keyv
Commit ee2681a, authored as the maintainer but unsigned, injects setup.mjs and Math_Symbol.js, plants a cover test, and rewrites the release tooling so the next version publishes under the latest dist-tag.
- 09:04
Editor and AI-agent hooks planted
A second commit adds .claude/settings.json (SessionStart hook) and .vscode/tasks.json (runOn: folderOpen), each executing a copy of the dropper. Opening the folder is enough to run it.
- 09:35
keyv@6.0.0 publishes with valid provenance
The project’s own release workflow publishes through GitHub Actions OIDC trusted publishing, carrying a genuine SLSA attestation. Provenance gates wave it through, because the provenance is real. The release process was subverted, not forged.
- 09:38
The worm starts publishing itself
Using credentials harvested from the first victims, the payload enumerates every package the stolen token can publish, injects itself, increments the patch version, and republishes. No attacker infrastructure is involved at any hop.
- 10:17
First public alarm
Issue jaredwray/cacheable#1689, "[URGENT] Repository compromised", already identifies it as a worm.
- 13:20
444 packages, 2,212 versions
Spread across @servicetitan (141), @onereach (78), @or-sdk (74), @ornikar (42), @qlik (28), @nebula.js (22) and others. npm unpublishes had begun at 10:39; by 18:10 all 11 tier-1 carriers were reverted.
Indicators of compromise
Defanged where they are attacker-controlled. Use these to hunt on developer machines and build runners, not just in lockfiles.
- node_modules/**/setup.mjsdropper; also aliased math_init.js and router_runtime.js
- node_modules/**/Math_Symbol.jsstage 2, 727,680 bytes
- $TMPDIR/bun-dl-*dropper staging directory
- $TMPDIR/tmp.dpkg_<pid>.lockworm state and beacon file
- .claude/settings.json, .vscode/tasks.jsonpersistence hooks injected into repos
On disk
- 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668setup.mjs, npm tarball preinstall loader
- fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1ebsetup.mjs, .claude and .vscode repository loader
- 9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bccMath_*.js stage 2
SHA-256
- npm-cache[.]comC2 domain observed in this campaign
- pypi-get[.]comC2 domain
- js-mirror[.]comC2 domain
- 0xE1f2395ee43e45A1556EC6438a88c31B83493103Ethereum mainnet contract serving the C2 list (EtherHiding). No fixed domain to sinkhole.
Network
- jaredwray · thiennq · hubsyncdevops · abarreir-ornikar · sitthidet_arv · rooci · picsart-npm-service-owner · onereach.userIf you maintain packages under any of these, audit for versions you did not publish.
Compromised npm publisher accounts
Questions people are asking
Am I affected by the ChainDrop npm worm?
You are affected if your dependency tree resolved to one of the 2,212 poisoned versions across 444 packages, directly or transitively, and you ran an install after 4 August 2026 09:35 UTC. Because the payload runs on a preinstall hook, installing was enough. Paste a lockfile into the checker on this page to compare it against the published list.
Which packages were compromised first?
keyv@6.0.0 was the first, published at 09:35 UTC on 4 August 2026 with over 153 million weekly downloads. Ten more full carriers followed from the same maintainer's projects, including flat-cache@6.1.24 and file-entry-cache@11.1.6. The worm then republished itself into 433 further packages using credentials stolen from each new victim.
Why did provenance and SLSA attestation not stop it?
Because the provenance was genuine. The attacker pushed a poisoned commit and tag to the source repository, and the project's own untouched release workflow built and published it through GitHub Actions OIDC trusted publishing. The signature attests that the workflow published the artifact, which is true. It does not attest that the source was clean.
Should I revoke my GitHub token immediately?
Not as the first step. The payload installs a monitor that fires when the stolen token is revoked. Clean the affected host first, then rotate credentials from a machine that never ran the install.
Is chaindrop.org connected to the ChainDrop worm?
No. chaindrop.org is a Web3 testnet faucet directory that has used the name since before this incident. Researchers independently named the worm ChainDrop in August 2026. The names collide; there is no connection. This page exists because people searching the name deserve accurate information rather than a coincidence.
Sources
Nothing on this page is original research. The affected-package list is parsed from the StepSecurity Threat Center snapshot of 4 August 2026, 18:10 UTC; the analysis is drawn from the reports below. Where they disagree, go to the source.
- ChainDrop supply chain compromise: anatomy of a self-propagating wormMicrosoft Threat Intelligence
- ChainDrop npm Worm: Bun-loaded CI/CD credential harvesterStepSecurity
- Shai-Hulud strikes again: CHAINDROP worm hits 400+ npm packagesElastic Security Labs
- ChainDrop: inside a self-propagating npm wormUnit 42, Palo Alto Networks
- Advisory AD-2026-009Cyber Security Agency of Singapore
- Massive ChainDrop npm supply-chain attack infects hundreds of packagesBleepingComputer
Also on chaindrop.org
This site tracks a different kind of expiry date: which Ethereum and L2 testnets are still alive, which are being retired and when. Sepolia support ends on 30 September 2026 and most tooling still defaults to it.