How the 'ChainDrop' Worm Weaponized Trusted npm Packages to Steal Developer Credentials

On August 4, 2026, a self-propagating worm named "ChainDrop" ripped through the Node Package Manager (npm) registry, poisoning 444 packages and 2,212 versions in under four hours. The attack hijacked some of the most heavily trafficked infrastructure in the JavaScript ecosystem, including the keyv storage library and flat-cache, which collectively see hundreds of millions of weekly downloads.[1][2]

Unlike typical malware that relies on typosquatting or obscure packages, ChainDrop compromised the primary maintainer of keyv. By pushing malicious files directly to the repository's main branch and immediately cutting a new release, the attackers weaponized the project's own automated workflows.[5]

This mechanism highlights a critical blind spot in modern supply chain security marketing. The poisoned versions were published to npm with valid SLSA provenance attestations, cryptographically signed by GitHub Actions. While provenance proves that a specific commit was built by a specific workflow, it cannot prove that the commit itself was authorized or benign.[2]

The attack, identified as a variant of the "Mini Shai-Hulud" malware family, executed its payload through a preinstall lifecycle hook. This abuses a legitimate npm feature that runs arbitrary commands before a package is fully installed, requiring zero interaction from the developer beyond running a standard npm install command.[3][4]

Once triggered, the dropper script—typically named setup.mjs—downloads a legitimate Bun JavaScript runtime alongside 710 kilobytes of heavily obfuscated second-stage code. This cross-platform payload targets Linux, macOS, and Windows environments, scanning developer workstations and continuous integration (CI/CD) pipelines for high-value secrets.[1][3]

The malware systematically harvests npm tokens, GitHub credentials, Amazon Web Services (AWS) keys, Kubernetes secrets, and HashiCorp Vault parameters. It also targets communication and payment infrastructure, scraping Slack and Stripe tokens from local environments.[5]

After encrypting the stolen data using embedded RSA-4096 public keys, the worm exfiltrates the secrets to dynamic HTTPS endpoints or public GitHub repositories. In a nod to previous campaigns, attackers labeled these dead-drop repositories with the description "Shai-Hulud: Here We Go Again."[1][5]

What elevates ChainDrop from a standard infostealer to a supply chain crisis is its automated propagation engine. After obtaining a developer's npm publishing token, the worm enumerates every other package that the compromised identity has the rights to modify.[1]

It then downloads the latest tarballs for those packages, inserts the malware and setup loader, increments the patch version, and republishes the modified packages back to the npm registry. This automated republication allowed the total number of malicious iterations to exceed 2,200 in a matter of hours.[1][2]

The worm also leverages stolen GitHub credentials to establish persistence in source code repositories. It injects configuration files for AI coding assistants like Claude and IDEs like Visual Studio Code directly into the codebase.[1][4]

By committing these hook files—often attributed to automated bot accounts to evade casual scrutiny—the attackers created an additional developer-to-developer infection path. Opening a repository checkout in a configured editor could trigger the payload even without running an npm install command.[4]

Security researchers note that dependency scanners often fail to detect these source-level hooks, as they look for known malicious packages rather than poisoned local configuration files. This technique mirrors earlier attacks targeting AI coding agents, demonstrating a shift toward exploiting developer productivity tools.[4]

The fallout from the ChainDrop campaign has forced a massive remediation effort across enterprise software environments. Organizations using affected packages, which include major platforms like Deliveroo and Qlik, must assume that any credentials present on infected machines have been compromised.[5]

Incident response teams advise developers to isolate affected systems immediately. Rather than simply deleting the malware, teams must preserve package tarballs, npm logs, and CI runner images to bound the exposure window and understand exactly what was stolen.[1]

Rebuilding CI runners, rotating all potentially exposed credentials, and auditing GitHub repositories for anomalous commits are now mandatory steps for affected organizations. The incident serves as a stark reminder that cryptographic signatures and automated checks are only as trustworthy as the human identities that control them.[1][6]