ChainDrop worm crawls into npm supply chain, evades standard defenses

A new variant of the Shai-Hulud npm worm has poisoned hundreds of packages while adding propagation techniques that can leave little trace in the corresponding source repositories. In Frank Herbert’s Dune, Shai-Hulud was the name of the giant self-sustaining desert sandworms that moved silently beneath the surface of the planet Arrakis. So it made sense that when some new self-replicating malware with computer worm-like behavior appeared in September 2025, security researchers would name it after Herbert’s fictional creatures. The latest variant of Shai-Hulud, dubbed “ChainDrop” by Microsoft and others, is no mere sequel, however. Now, the npm community is discovering a Shai-Hulud variant spreading with new stealthy superpowers that circumvent the usual safeguards of open source repositories. On August 4, multiple security researchers identified a large-scale npm supply chain attack using this Shai-Hulud variant that had infected 444 packages from multiple publishers, which are collectively downloaded about 2 billion times a month. The operation targeted widely used deep infrastructure dependencies, such as keyv, flat-cache and cache-manager. Abby Kearns, CEO of enterprise open source security company ActiveState, noted in a Medium post that what is unique about this particular attack is that it doesn’t use the typical methods of breaching the defenses of open source repositories. Even if you never install an infected package (“npm install” in npm argot), you can still get the nasties – though that is one possible route of infection. Once triggered, ChainDrop also places startup hooks into the repository configuration files themselves: Simply opening an infected Git branch in VS Code or Claude Code can bring your repository under ChainDrop’s control. Scouring your code itself may not provide evidence of tampering. ChainDrop propagates not by repository source commits but by tarballs, an archive format for downloading file packages. ChainDrop travels by tarball When executed, the software scours the user’s workspace for npm tokens with full write privileges, as well as for other credentials like cloud keys and secrets. It looks in shell configurations, environment variables and even live memory. Any purloined data is encrypted and sent back to attacker-controlled endpoints. Should it find an npm token, it then downloads the tarballs of all the packages that token has full access to, bypassing the repositories themselves. That’s the genius part: ChainDrop self-replicates by rebuilding the tarball to include its own payload. Reviewing the source code repository won’t reveal any evidence of shenanigans. ChainDrop’s attack is two-pronged. It also searches for GitHub credentials. If it finds any, it queries the GitHub API to list all accessible repositories and branches and then commits its malicious configuration code directly into those branches. So when other developers open these repositories using Claude or VS Code, a background task gets triggered that harvests credentials, beginning the whole cycle anew. What a dev can do This attack is particularly pernicious because npm is widely integrated into automated CI/CD pipelines, which can automatically pull patch updates for dependencies during a rebuild - giving the worm a path to wiggle into fresh builds. If you think you've been infected, the first thing to do is check for any .claude/settings.json and .vscode/tasks.json files you did not add yourself, ActiveState’s Kearns advised. And don’t just check the main branch, but all the other branches as well. All the infected packages were quickly yanked from npm. Open source security firm SafeDep offers a list of all the compromised packages along with version numbers, so check those against what you currently have running. Beyond cleaning up the mess, developers and security teams should rethink how their systems could be breached in light of ChainDrop. Trusted publishing tools such as GitHub Actions should be evaluated, for starters. Begin “treating repository-supplied configuration as executable content, because that is what it is now,” Kearns wrote. “What this campaign really found was an execution path that dependency scanning tools were not configured to look at, sitting inside the exact tools engineering organizations have spent two years adopting as fast as they could,” Kearns wrote. “This is the first campaign to notice the gap and use it at scale. It will not be the last one.” ®

Indexed and credited by AIPROPX. Originating outlet: The Register. Open at source →