ChainDrop: What the New npm Supply Chain Worm Means for Your Build & What to Do Right Now 

A new, self-propagating supply chain worm, dubbed ChainDrop, is actively spreading through the npm ecosystem. Discovered and documented by Microsoft Threat Intelligence and others, the campaign has already touched more than 400 npm packages across multiple unrelated publishers, including widely used packages in the keyv, flat-cache, and cache-manager ecosystems. 

This is not a single compromised library. It’s a worm. One stolen publishing token can produce malicious patch releases across every package that token can write to; each of those packages becomes a new propagation node. If your team installs npm packages, this is a now problem, not a next-quarter problem. 

What happened 

According to Wiz’s analysis, the attack began with the compromise of a GitHub maintainer account in the keyv/cacheable ecosystem. At 09:00 UTC, the attacker used the compromised identity to introduce persistence payloads into the keyv repository, then shortly after published a new malicious version of keyv. From there, the worm propagated to over 400 distinct npm packages. 

The blast radius is enormous. keyv alone sees more than 600 million monthly downloads; related caching packages push the combined exposure into the billions of installs, and transitive risk reaches nearly every modern JavaScript project and CI runner. 

Microsoft Threat Intelligence identified the payload as a Mini Shai-Hulud variant (a descendant of a known credential-stealing malware family) delivered through a large, heavily obfuscated Bun-based JavaScript payload. 

How the worm works 

The mechanics are what make ChainDrop dangerous. Here’s the chain of events, drawn from Microsoft’s and Wiz’s reporting: 

  1. Initial access via compromised maintainer credentials. The attacker gains control of a legitimate maintainer’s GitHub/npm identity. 
  2. Install-time execution. The malware runs automatically through an npm preinstall lifecycle hook. This executes before the package installation even completes. Simply running npm install on a tainted package is enough to trigger it. 
  3. Credential harvesting. Once executed, the malware searches developer workstations and CI/CD environments for credentials tied to npm, GitHub, AWS/GCP/Azure, Kubernetes, HashiCorp Vault, SSH keys, and even IDE and AI assistant configurations (including Claude Code and VS Code). It authenticates with recovered identities to enumerate packages, repositories, workflow secrets, cloud parameters, and secret-store values. 
  4. Self-propagation. This is the worm’s defining capability. After stealing an npm publishing token, the malware enumerates every package that token can publish to, downloads the latest tarball, injects the malware and a loader, adds a preinstall hook, increments the patch version, and republishes the modified package. One stolen token begets hundreds of malicious releases. 
  5. Exfiltration and persistence. Stolen data is encrypted and sent to an attacker-controlled HTTPS endpoint, with GitHub repositories created under compromised identities serving as a fallback exfiltration channel (marked with the description “Shai-Hulud: Here We Go Again”). Persistence is established through Claude Code hooks and VS Code tasks.json files, creating an additional developer-to-developer infection path. 
  6. Resilient command-and-control. Wiz found that the malware retrieves its C2 domains from an Ethereum smart contract (StringListStore) via an eth_call, rather than hardcoding them. This lets the operator rotate C2 infrastructure, – currently resolving to npm-cache[.]com, – without touching the malware itself. 

            One detail worth flagging for defenders: valid provenance/SLSA signatures were present in multiple waves of the attack, which means simple signature checks alone do not catch this. A package can be “signed and legitimate-looking” and still be malicious. 

            Why ChainDrop is different 

            Supply chain attacks are not new. What makes ChainDrop stand out is the combination of: 

            • Scale and speed. 400+ packages compromised through automated worm propagation, not manual one-off publishes. 
            • Install-time trigger. No user interaction beyond npm install is required. 
            • Bypassed integrity signals. Valid provenance signatures defeat naive signature verification. 
            • CI/CD as a force multiplier. Every build runner that resolves an affected package becomes a propagation node, turning a single compromise into an ecosystem-wide event. 

            The first-principles lesson is blunt: one compromised publishing token plus install-time execution turns every downstream developer and CI pipeline into a propagation node. The blast radius is ecosystem-wide and, as of this writing, ongoing. 

            What to do right now 

            If you’re responsible for application security or platform engineering, treat this as an active incident: 

            1. Identify and remove affected package versions from all development, build, and CI/CD environments. Run a full inventory scan of all npm lockfiles across your repositories and pipelines. 
            2. Rotate every credential that may have been exposed — npm and GitHub tokens, cloud credentials (AWS/GCP/Azure), Kubernetes secrets, Vault access, and CI/CD secrets — in any environment that may have resolved affected package versions. Rebuild from clean, verified sources. 
            3. Pin and verify dependencies. Lock your dependencies to known-good versions via lockfiles, enforce reproducible builds, and maintain an up-to-date SBOM so you can answer “are we exposed?” in minutes, not days. 
            4. Harden publishing credentials. Restrict npm publishing tokens to the minimum required scope, enable strong 2FA on maintainer accounts, revoke any tokens that may be compromised, and check for other compromised identities. 
            5. Monitor for the tell-tale signs. Watch for unexpected preinstall hooks or modified lifecycle scripts in dependencies, and for new GitHub repositories created under your identities with the “Shai-Hulud” description. 

                    How Veracode helps with ChainDrop and software supply chains security

                    Attacks like ChainDrop are exactly the scenario our supply chain controls are built for. Our defenses map cleanly to the threat: 

                    • Package Firewall blocks known and newly identified malicious package versions at the policy gate, before they enter your build. With a worm that triggers on npm install, blocking at the gate is the difference between a contained incident and an organization-wide compromise. Learn more → 
                    • Software Composition Analysis (SCA) gives you continuous visibility into what’s actually in your applications, across all your npm lockfiles and CI pipelines, so you can pinpoint exposure fast. Learn more → 
                    • Software Supply Chain Intelligence (SSCI) adds a proprietary threat feed that surfaces active campaigns like ChainDrop as they evolve, so you’re working from current intelligence rather than yesterday’s news. Learn more → 
                    • SBOM provides the immediate, shareable intelligence you need to answer exposure questions across teams and pass them upstream to leadership. 
                    • Risk Manager elevates priority based on blast radius and active-exploitation signals, so the most urgent issues surface to the top instead of getting lost in the backlog. Learn more → 

                    The practical takeaway: enable and enforce Package Firewall policies that quarantine any package matching the current campaign indicators, run a full SCA + SSCI inventory across all repositories and CI pipelines, and let Risk Manager drive prioritization. That sequence – block, inventory, prioritize – is the fastest path from “are we exposed?” to “we’re covered.” 

                    The bottom line 

                    ChainDrop is a reminder that the software supply chain is only as trustworthy as its weakest publishing token. The worm spreads because npm install is treated as safe by default, and because one compromised maintainer can reach billions of downstream installs in hours. The defense isn’t a single tool; it’s a gate that blocks malicious packages before they execute, continuous intelligence that tracks the campaign as it mutates, and an inventory you can trust. If your team is in frantic work mode right now, you’re not alone. The good news is the controls to stop this at the gate already exist. 

                    Want to talk through how Veracode can help you block ChainDrop and the next supply chain worm? Contact us to learn more.