ChainDrop worm spreads across hundreds of npm packages

A self-propagating malware campaign has compromised more than 430 npm packages, exposing software projects linked to dependencies that collectively record about two billion installations each month.

The campaign, known as ChainDrop, emerged on 4 August after attackers gained control of the account behind Keyv, a widely used caching library in the JavaScript ecosystem. Malicious code was then introduced into Keyv and several related packages, including flat-cache, file-entry-cache and cacheable, allowing the infection to spread through interconnected developer accounts and publishing permissions.

Security investigators have linked the operation to the Shai-Hulud malware family, which first appeared in September 2025. The latest wave represents a sharp escalation in both reach and technical sophistication. Earlier versions relied mainly on stolen npm authentication tokens. ChainDrop can also exploit trusted publishing systems and legitimate software release workflows.

Once installed, the worm searches development machines and automated build environments for credentials. Its targets include npm and GitHub tokens, cloud access keys, SSH credentials, Kubernetes configuration files, secrets stored in continuous integration systems and authentication material used by development tools.

The malware then identifies packages that a compromised account is authorised to publish. It inserts its payload into those packages and releases infected versions through npm, allowing the operation to expand without requiring attackers to compromise each project manually.

This mechanism turns affected maintainers and companies into involuntary distribution points. An organisation may therefore be both a victim and a source of additional infections if compromised credentials are used to publish poisoned software.

Keyv’s position within the JavaScript dependency network increased the potential impact. The library provides a common storage interface used by applications, frameworks and supporting tools. Related packages are frequently installed indirectly, meaning developers may be exposed without having selected an affected library themselves.

The figure of two billion monthly installations reflects the combined usage of the affected packages rather than a confirmed number of infected computers. Download and installation statistics for open-source packages often include automated builds, cached deployments and repeated activity by the same systems. The total nevertheless illustrates the scale of the software potentially connected to the compromised dependency chain.

ChainDrop has also weakened confidence in provenance attestations, which are designed to show where and how a software package was built. Some poisoned packages were reportedly released through genuine build pipelines and therefore carried valid cryptographic provenance information.

Such attestations can confirm that an authorised workflow produced a package. They cannot establish that the workflow, source code or credentials were secure at the time. A malicious release generated through a compromised but legitimate pipeline can consequently pass checks that would reject an unauthorised upload.

Investigators found that the worm could resolve its command-and-control infrastructure through an attacker-controlled Ethereum smart contract. This allows operators to change server addresses without modifying the malware itself, reducing the value of conventional domain and internet protocol blocklists.

The technique still leaves detectable behaviour. Build systems normally have little reason to communicate with public blockchain gateways. Unexpected connections from development or continuous integration environments to Ethereum infrastructure may therefore indicate compromise.

The malware can also create public GitHub repositories to store encrypted collections of stolen credentials. This enables the traffic to blend with ordinary communication between developer systems and a trusted code-hosting platform.

Persistence mechanisms extend beyond package installation. The worm can alter Visual Studio Code task files, inject workflows into repositories and add hooks to AI coding assistants. These changes may cause malicious components to run again when a developer opens a project or starts a new coding session.

Some variants monitor whether stolen tokens remain active and may trigger destructive behaviour after credentials are revoked. Incident responders have therefore advised organisations to remove persistence mechanisms before rotating tokens, purging caches and rebuilding systems from verified sources.

Projects that installed affected package versions are being urged to treat developer workstations and build servers as potentially compromised. Removing the package alone may not eliminate stolen credentials, altered workflows or code added to local editor configurations.

Defensive measures include pinning dependencies to exact versions, committing lockfiles, delaying the adoption of newly published releases and disabling npm installation scripts unless they are specifically required. Companies are also tightening outbound network access from build systems and limiting the permissions available to publishing workflows.

Internal package mirrors, continuous integration caches and local npm directories require separate checks. A malicious version removed from the public registry may continue to circulate from private repositories or cached copies inside an organisation.