Skip to content

Back to the catalog

ChainDrop npm Worm: Bun-loaded CI/CD credential harvester with Ethereum dead-drop C2
stepsecurity.iowriteup

ChainDrop npm Worm: Bun-loaded CI/CD credential harvester with Ethereum dead-drop C2

Analysis of 'ChainDrop', an npm supply-chain worm that uses the Bun JavaScript runtime to execute a payload harvesting CI/CD credentials, with command-and-control coordinated via dead-drop messages posted to the Ethereum blockchain. The campaign is notable for combining a self-propagating npm worm technique with blockchain-based C2 to evade takedown and for targeting CI/CD secrets specifically.

TL;DR npm worm 'ChainDrop' uses Bun to steal CI/CD credentials and coordinates via an Ethereum blockchain dead-drop C2.
Open original ↗
Document

What it is

ChainDrop is a self-propagating npm supply-chain worm that hit npm on August 4, 2026, poisoning 444 packages / 2,212 versions in under four hours, including keyv@6.0.0 (~150M weekly downloads), flat-cache@6.1.24 (149.9M), and file-entry-cache@11.1.6 (147.6M) — packages sitting under ESLint, cache-manager, and cacheable. StepSecurity assesses it as a heavily evolved descendant of the Shai-Hulud 2.0 worm. The incident is still developing and counts are increasing.

How it works

Two tiers. The initial compromise was 11 full worm carriers in the jaredwray ecosystem, each shipping an obfuscated setup.mjs loader ("preinstall": "node setup.mjs") plus a 727,680-byte Math_Symbol.js (renamed math_init.js in the second wave). The preinstall dropper downloads the legitimate Bun runtime to execute the 710 KB obfuscated stage 2, which harvests credentials, republishes packages, and burrows into AI developer tooling (Claude Code, VS Code, GitHub Copilot). The worm's own work then republished 433 more packages (2,201 versions) using harvested CI credentials, each carrying the Bun downloader stager.

The critical detail: the headline packages shipped through npm's OIDC Trusted Publishing with valid SLSA provenance attestations. The attacker compromised the maintainer's GitHub account, pushed poisoned commits/tags, and let the projects' own release workflows build and attest the malware. Provenance proves which commit was built — not that the commit was authorized. Unlike the March 2026 axios compromise, absence of provenance is not a usable signal here.

What to do

  • Check package-lock.json, yarn.lock, pnpm-lock.yaml for affected versions, including transitive deps — don't rely on the headline list.
  • If present, treat any machine or CI runner that installed them as compromised. Rotate all secrets in those environments (npm tokens, cloud creds, SSH keys, CI secrets).
  • Remove the token monitor before rotating. The worm installs a watcher that fires an attacker payload when the stolen GitHub token is revoked.
  • Pin/roll back to a known-good version; avoid npm install/npm update against latest until maintainers confirm clean releases.
  • Audit for install-time persistence in build artifacts, dev machines, and CI caches.

Caveats

Active investigation; every count is a snapshot as of Aug 4, 2026 18:10 UTC and rising as the worm republishes. The listed 11 carriers and headline packages are not the full set — StepSecurity says the list is likely incomplete.

flowchart TD
    A[GitHub account compromised] --> B[Poisoned commit + tag pushed]
    B --> C[Project's own release workflow builds]
    C --> D[Published with valid SLSA provenance]
    D --> E{Provenance check}
    E -->|passes: proves commit built,<br/>not authorized| F[preinstall: node setup.mjs]
    F --> G[Downloads Bun runtime]
    G --> H[710KB stage 2: harvest creds]
    H --> I[Republish 433+ packages via stolen CI creds]
    I --> B
    H --> J[Token monitor: fires on revocation]

Technologies named here

Threat actors named here

Related in Supply Chain