ChainDrop npm Worm Weaponizes Dev Tools and Tarballs in Massive Supply Chain Attack

A sophisticated npm supply chain attack leveraging a new Shai-Hulud variant known as ChainDrop has compromised 444 open-source packages, affecting core dependencies downloaded roughly two billion times per month. First identified on August 4, this self-propagating worm introduces a dangerous evolution in software supply chain attacks by completely decoupling malicious code injection from public source code repositories and abusing developer workspace configurations in tools like Visual Studio Code and Claude Code.

Initially surfacing in September 2025, the original Shai-Hulud malware family gained notoriety for its worm-like self-replication across developer environments. The ChainDrop variant, identified by Microsoft and other security teams, elevates this threat by exploiting blind spots in standard Software Composition Analysis (SCA) tools and CI/CD pipelines. Rather than leaving a visible paper trail of malicious commits in Git history, ChainDrop executes covertly in the developer workspace and manipulates published registry artifacts directly.

How ChainDrop Evades Traditional Source Code Scanning

The core innovation of the ChainDrop attack is its reliance on direct tarball manipulation rather than source repository poisoning. Traditional supply chain security practices often assume that the code stored in a public Git repository matches the code published to a package registry like npm. ChainDrop shatters this assumption.

When the worm executes on an infected machine, it scans the workspace, environment variables, shell configuration files, and live system memory for sensitive credentials. It specifically searches for npm authentication tokens with write privileges, as well as cloud API keys and secret tokens. Any stolen credentials are encrypted and exfiltrated to attacker-controlled endpoints.

If ChainDrop successfully harvests a write-capable npm token, it queries the registry for all packages managed by that account. Instead of cloning the source repositories and pushing malicious commits—which would be easily flagged during pull request reviews or Git history audits—ChainDrop downloads the existing tarballs directly from npm. It unpacks the archives, injects its self-replicating payload into the compiled package files, rebuilds the tarballs, and uploads the infected packages back to the registry under the same release versions or patch updates.

Because the underlying GitHub or GitLab repository remains untouched, developers auditing source repositories or running static analysis against source code will find no trace of tampering, even while the published npm artifact carries active malware.

Weaponizing Developer Tools via Workspace Hooks

To initial-infect developer systems and propagate across organizations, ChainDrop exploits workspace configuration hooks in popular development environments, notably VS Code and Anthropic’s Claude Code assistant.

When ChainDrop acquires GitHub credentials during its memory and environment harvest, it uses the GitHub API to enumerate every accessible organization, repository, and branch available to the compromised user. The worm then automatically commits malicious configuration files directly to those branches. Specifically, it targets:

• .vscode/tasks.json in Visual Studio Code
• .claude/settings.json in Claude Code

These files allow project maintainers to define automated background tasks, pre-build scripts, or tool integrations that execute when a repository is opened. When another developer clones or checks out an infected branch and opens it in their editor, the IDE automatically parses these configuration files and triggers the embedded background tasks.

This immediate, silent execution launches the credential harvester on the new host, extracting local secrets and initiating the tarball modification cycle for any npm packages associated with the new victim’s tokens. Because developers frequently work across feature branches that may not undergo immediate main-branch security reviews, side branches become persistent vectors for workspace compromise.

Scope, Blast Radius, and Impact

The campaign targeted several foundational infrastructure packages heavily relied upon throughout the JavaScript and Node.js ecosystems. Among the 444 infected packages were widely used caching and utility libraries, including keyv, flat-cache, and cache-manager.

Because these libraries sit deep within the dependency trees of enterprise applications, their compromise created a massive downstream blast radius. Automated CI/CD pipelines configured to pull patch updates or floating version ranges during automated builds inadvertently pulled the infected registry tarballs directly into fresh application builds.

Even organizations that enforce strict code review policies were left exposed if developers opened untrusted pull requests locally or if CI systems pulled updated tarballs whose modified payloads bypassed source-level code analysis.

Detection and Remediation Guidance

All 444 compromised package versions identified in this campaign were yanked from the primary npm registry shortly after discovery. However, security teams must address potential local caching, mirror registry persistence, and active workspace infections.

1. Inspect Workspace Configurations: Scan all Git repositories and active branches across your organization for unauthorized additions to .vscode/tasks.json and .claude/settings.json. Do not limit scans to main or release branches; inspect all remote feature branches and pull requests.
2. Audit Installed Dependencies: Cross-reference build manifests and lockfiles against the full list of compromised package versions published by open-source security firm SafeDep. Flush local build caches and private proxy registries (such as Nexus or Artifactory) to prevent re-installation of yanked packages.
3. Revoke and Rotate Credentials: If an engineer opened an infected repository branch or ran an infected package build, assume all environment variables, shell configs, and memory-resident keys on that machine are compromised. Immediately revoke npm publish tokens, cloud access keys, and GitHub personal access tokens associated with impacted workstations.
4. Transition to Granular and Ephemeral Auth: Migrate npm publishing workflows to use Granular Access Tokens or Trusted Publishers (OIDC via GitHub Actions) to eliminate persistent, long-lived npm write tokens stored on local developer machines.
5. Treat Configuration as Executable Code: Restrict auto-execution settings in developer tools. In VS Code, ensure Workspace Trust settings require explicit authorization before running workspace tasks (task.allowAutomaticTasks: "off"). Engineering teams must treat repository-supplied configuration files with the same security scrutiny as compiled code or executable binaries.