Skip to content
HACKTECH
Supply chainReported Published 4 sources

ChainDrop worm spreads from hijacked keyv maintainer account to hundreds of npm packages

On 4 August 2026 an attacker who had compromised the GitHub account of the keyv maintainer pushed malicious files to project main branches and cut releases, so poisoned versions of keyv, flat-cache, file-entry-cache, cache-manager and related packages were published to npm with valid provenance through the projects' own GitHub Actions workflows. The worm, which the community nicknamed ChainDrop and Datadog compares to Shai-Hulud, then used stolen npm tokens to republish other maintainers' packages. Published counts differ: Microsoft counted 'more than 400 packages across multiple unrelated publishers', Aikido's 5 August update said at least 444 packages across 1,381 versions, and BleepingComputer reported more than 1,300 packages and said the count was expected to grow. The install-time payload stole npm, GitHub, AWS, Kubernetes and HashiCorp Vault credentials.

  • ChainDrop
  • Shai-Hulud
  • npm
  • keyv
  • worms
  • package provenance
  • GitHub Actions
  • OIDC
  • AI coding assistants

What the sources report

  • Datadog traced the earliest malicious state to an unsigned commit at 09:02:37 UTC on 4 August 2026; keyv@6.0.0 reached npm at 09:35 UTC, and nine cacheable-family versions, including flat-cache@6.1.24, file-entry-cache@11.1.6 and cache-manager@7.2.10, followed between 10:09:44 and 10:14:41 UTC.
  • Infected packages gained setup.mjs and Math_Symbol.js plus a 'preinstall': 'node setup.mjs' entry; the dropper downloads the Bun runtime from GitHub to run the obfuscated stealer (Aikido, BleepingComputer).
  • On GitHub Actions runners the payload reads runner process memory and steals OIDC tokens used for npm publishing; with a classic token holding workflow scope it injects a workflow exposing ${{ toJSON(secrets) }}, then deletes the branch and run (Aikido, Datadog).
  • With GitHub credentials it commits to up to 50 branches per repository, adding hooks to .claude/settings.json and .vscode/tasks.json so the payload runs when the repository is opened in VS Code or a Claude Code session starts; Aikido saw these commits authored as 'claude' with the message 'chore: update config' (Aikido, Datadog).
  • Datadog and Microsoft found the primary exfiltration domain is read from an on-chain contract, which Datadog identifies as an Ethereum smart contract, with a public GitHub repository described 'Shai-Hulud: Here We Go Again' as a fallback; Aikido counted roughly 1,300 such repositories at the time of writing. Data is encrypted with AES-256-GCM and the key wrapped with RSA-OAEP (Datadog, Microsoft).
  • Microsoft recommends npm CLI v12's min-release-age feature, purging npm and yarn caches, rotating credentials from a clean host and rebuilding from a known-good dependency baseline; BleepingComputer advises treating any workstation or CI/CD runner that installed an affected version as compromised even after the package is removed.

What it means for your organisation

The poisoned releases carried valid provenance because the projects' genuine workflows built them from code pushed with a genuine account, so provenance checks alone would not have flagged them. The worm also wrote AI-assistant and editor configuration files into repositories, turning the act of opening a project into an execution trigger. Required review on default branches and a minimum release age for new dependency versions target the two halves of that chain.

What we check

  • Search lockfiles, artefact repositories and CI caches for the compromised versions, including transitive dependencies.
  • Review branch protection so a single stolen account cannot push to a default branch and trigger a release without review or signed commits.
  • Look for unexpected .claude/settings.json, .vscode/tasks.json or workflow files, and for public repositories described 'Shai-Hulud: Here We Go Again' under staff accounts.
  • Inventory npm tokens with 2FA bypass and classic GitHub tokens with workflow scope, and check whether each can be replaced with a short-lived, narrowly scoped credential.
  • Identify every runner or workstation that installed an affected version, and confirm each was rebuilt and every secret it could reach was rotated.
  • Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

  • A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.