- ChainDrop, a self-replicating worm, compromised 435 npm packages and 1,557 malicious versions in under four hours.
- The malware uses Ethereum blockchain for command and control (EtherHiding) and steals credentials from development environments.
- Initial infection came from a compromised GitHub account of the maintainer of keyv and cacheable packages.
- Developers must revoke all credentials, audit repositories, and treat affected machines as fully compromised.
The software supply chain took another heavy hit on August 4, 2026, when a self-propagating worm called ChainDrop flooded the npm registry with over 1,500 malicious package versions. The attack, which security firms are calling a direct descendant of the Shai-Hulud worm, managed to compromise more than 435 unique packages in a matter of hours. What makes this incident particularly nasty is that the malware didn’t just sit there—it actively stole credentials, used them to publish even more infected packages, and even left behind persistence mechanisms in developer tools like Claude Code and Visual Studio Code.
According to reports from StepSecurity, Aikido, and JFrog, the attack began when an attacker gained control of the GitHub account belonging to Jared Wray, the maintainer of widely used packages like keyv and cacheable. From there, they injected malicious code directly into the main branch, created release tags, and let the legitimate GitHub Actions workflows publish the tainted versions to npm. The whole operation was highly automated: within less than four hours, 2,212 malicious versions were initially reported, though later analysis refined that number to 1,557 versions across 435 packages. The discrepancy comes from early confusion between package names, version numbers, and exfiltration repositories—a common mess in fast-moving supply chain attacks.
The Origin and Scale of ChainDrop
ChainDrop didn’t come out of nowhere. It’s an evolved version of the Shai-Hulud worm, and it shares many of the same techniques. The initial breach targeted the npm ecosystem through 11 carrier packages under the keyv and cacheable namespaces. These carriers contained the full loader and worm code, weighing in at about 727 KB. Once the attacker had access, they used stolen npm tokens to enumerate all packages available to the compromised identity, download their tarballs, inject the malware, bump the patch version, and republish them. This cycle repeated rapidly, leading to the 1,557 malicious versions observed between 09:35 and 11:44 UTC.
Early reports from BleepingComputer mentioned over 1,300 packages, but that figure turned out to be a mix of actual npm packages and public GitHub repositories used for data exfiltration. The real count, as confirmed by StepSecurity at 16:20 UTC, stands at 435 unique packages and 1,557 versions. The affected libraries include keyv, flat-cache, file-entry-cache, cacheable-request, cache-manager, and ecto, among others. Many of these are transitive dependencies, meaning a developer could have run the malicious code without ever directly adding keyv to their project. The combined weekly downloads of these packages exceed 500 million, amplifying the potential blast radius.
How the Malware Works: Infection and Propagation
Each infected package included a preinstall script that executed setup.mjs before npm install completed. That script downloaded the official Bun 1.3.13 runtime from GitHub and used it to run a heavily obfuscated second-stage payload called Math_Symbol.js, which was about 728 KB in size. The use of a legitimate runtime like Bun made the traffic look normal, helping the malware fly under the radar. Once active, the payload scoured the developer’s machine or CI runner for secrets: npm and GitHub tokens, AWS and Azure credentials, HashiCorp Vault tokens, SSH keys, .env files, Stripe keys, Slack tokens, and even credentials stored by AI coding assistants.
The stolen data was encrypted and exfiltrated to public GitHub repositories with the description “Shai-Hulud: Here We Go Again.” But the malware didn’t stop there. It also used a technique called EtherHiding, which leverages the Ethereum blockchain for command and control. The C2 server address was resolved through a smart contract, making it extremely hard to block. Additionally, ChainDrop installed a host-level kill switch: it checked the GitHub API every 60 seconds with the stolen token, and if the token stopped working, it would delete its state and exit. It also self-destructed after 24 hours, complicating forensic analysis.
The worm’s self-replication capability was its most dangerous feature. After stealing credentials, it would authenticate to npm, enumerate all packages the compromised identity could publish, and then republish each one with the same preinstall hook. This allowed the infection to spread from developer to developer, turning every compromised machine into a launchpad for new attacks. The malware also modified .claude/settings.json and .vscode/tasks.json to ensure persistence even after node_modules was deleted.
Impact and Recommendations for Developers
If you or your team installed any of the affected package versions during the exposure window, you need to treat your machines as fully compromised. A single npm install was enough to trigger the loader. The first step is to isolate the affected systems and preserve logs, tarballs, and CI records for later analysis. Then, from a clean machine, revoke and rotate all credentials that were accessible to the process: npm tokens, GitHub tokens, cloud provider keys, SSH keys, CI secrets, and any other sensitive data. Don’t forget to check for unexpected changes in .claude, .vscode, and GitHub Actions workflows.
Security firms like JFrog, StepSecurity, and Socket all emphasize that simply updating the package or deleting node_modules is not enough. The malware may have left behind persistence mechanisms that can re-infect the system. You need to remove the token monitor and persistence components first, as described in the detailed analyses, before revoking credentials. After that, fix your lock files to exact clean versions and consider reinstalling with scripts disabled until the investigation is complete.
One of the most unsettling aspects of ChainDrop is that many of the malicious versions carried valid SLSA attestations. Because the attacker used the legitimate GitHub Actions workflows of the compromised repository, the provenance system confirmed that the package was built from the claimed commit and by the expected workflow. The problem was that the commit itself was malicious. This incident shows that a valid signature or attestation is not a guarantee of trust—you also need to verify that the change was authorized by the maintainer. Defenses like enforcing a minimum age for new releases, restricting install scripts, and pinning dependencies by integrity can help mitigate similar attacks in the future.
The ChainDrop attack is a stark reminder that the open-source ecosystem’s trust model has a critical blind spot. Even when every technical check passes—signed commits, trusted publishing, SLSA attestations—a single compromised maintainer account can bring down the whole house. The community needs to move toward more robust verification methods, such as requiring multi-factor authentication for publishing, monitoring for unusual activity in repositories, and maintaining a real-time inventory of what actually runs in CI pipelines. Until then, developers will have to stay vigilant and treat every new release with a healthy dose of skepticism.
