ChainDrop npm Worm Compromises 444 Packages via GitHub Actions

Key Takeaways

• A sophisticated npm supply chain attack, dubbed “ChainDrop” by Microsoft, compromised 444 packages and over 1,300 malicious releases.
• The attack leveraged stolen GitHub credentials and exploited trusted publishing workflows, impacting packages with over two billion monthly downloads.
• Uniquely, the threat bypassed typical package installation monitoring by injecting malicious configuration files into repositories, capable of executing code upon project opening in IDEs like VS Code or AI tools like Claude Code.
• This incident highlights a critical blind spot in current software supply chain security, where repository configurations are not routinely inspected for executable content.
• Immediate mitigation requires revoking compromised credentials, resetting CI/CD environments, and thoroughly auditing all repository branches for unexpected configuration files.

A new npm package compromise, dubbed “ChainDrop” by Microsoft and “Mini Shai-Hulud” by other researchers, has exposed a significant vulnerability within the software supply chain, affecting an alarming 444 packages and leading to over 1,300 malicious releases. The self-propagating campaign, which exploited GitHub Actions and npm’s trusted publishing mechanisms, served as a stark warning about the potential for developer machines to become vectors for widespread compromise. These affected packages collectively account for more than two billion monthly installations, underscoring the attack’s broad reach.

The ChainDrop operation’s ingenuity lay in its ability to spread through legitimate channels, utilizing stolen npm publishing tokens. Beyond merely poisoning packages, the attackers manipulated repository configurations to execute code when a developer simply opened a project in environments like VS Code or initiated a Claude Code session. This means that a standard Git clone and subsequent project open could inadvertently trigger the malicious payload, circumventing traditional supply chain security controls that primarily monitor package installations.

According to Abby Kearns said in a report, the critical distinction of this attack was the adversary’s deliberate choice to bypass the installation step, a phase typically scrutinized by supply-chain security tools. This sophisticated maneuver highlights a fundamental gap in how engineering teams often perceive and inspect repositories—primarily as static source code, rather than as dynamic content capable of instructing local development tools to perform actions.

ChainDrop npm Worm: A Deep Dive

The attack commenced on August 4 with the initial compromise of the GitHub account responsible for the Keyv caching library and associated packages, including cacheable, flat-cache, and file-entry-cache. Attackers leveraged stolen credentials to push modified releases, subsequently harvesting additional publishing access to propagate the infection further. Projects configured to automatically track the newest major versions were particularly susceptible, while those with older, pinned major versions remained protected.

A critical aspect of the ChainDrop campaign was its exploitation of npm’s trusted publishing system via GitHub Actions. Malicious releases appeared legitimate because they carried valid provenance attestations. This meant that the records indicated an approved identity performed the release through a GitHub Actions workflow configured as an npm trusted publisher. The core issue, however, originated upstream: malicious code was injected into the repository before the trusted workflow even executed. This echoes prior warnings about GitHub Actions workflow weaknesses reported earlier this year.

This distinction is crucial: while provenance confirms a build’s origin, it does not guarantee that the generating computer, account, or repository was free of compromise. In the ChainDrop incident, no signatures were forged, and no publishing pipelines were directly broken. Instead, attackers exploited legitimate access within an ecosystem designed for trust. Responding to this complex threat required the Keyv maintainer to perform extensive remediation, including wiping affected machines, disabling GitHub Actions and trusted publishing, withdrawing compromised versions, removing malicious branches and tags, and resetting impacted branches.

Repository Files Become an Execution Path

Beyond package compromise, ChainDrop introduced two malicious configuration files into as many as 50 different repository branches. One file injected a Claude Code SessionStart hook, while the other defined a VS Code task designed to execute upon folder opening. Both configurations were capable of launching a dropper from the other tool’s directory, enabling code execution without requiring an npm install or build command.

This novel approach evades many conventional dependency scanners, which typically focus on manifest and lock files to identify downloaded packages. These scanners often overlook project settings that define editor tasks or AI coding-tool behaviors. The risk profile is akin to a compromised automation action incident, where trusted development automation becomes the gateway to sensitive system access.

While features like VS Code Workspace Trust and Claude Code trust checks can prevent automatic execution in untrusted projects, the danger escalates once a developer has already marked a familiar repository checkout as trusted. To counter this, Kearns advises development teams to meticulously scan every branch, not just the main branch, for unexpected repository configurations and to cross-reference resolved package versions against known malicious releases.

Organizations must begin treating repository-supplied configurations as potentially executable content. This necessitates integrating these file paths into regular security reviews, monitoring processes, and incident response protocols. Furthermore, teams should inventory all coding tools, scrutinize files read during project opening, restrict high-value tokens, and remain vigilant for previous npm package compromises that might signal similar credential theft. The ChainDrop incident unequivocally demonstrates that a clean dependency tree alone is no longer sufficient to guarantee a secure developer workspace.

What You Should Do

• Revoke and Rotate Credentials: Immediately revoke all GitHub and npm tokens or credentials associated with any potentially compromised accounts. Implement a regular rotation schedule for all sensitive credentials.
• Audit GitHub Actions and Workflows: Review all GitHub Actions workflows, especially those configured for trusted publishing, to ensure they only execute expected and secure operations. Limit permissions to the absolute minimum necessary.
• Inspect Repository Configurations: Implement automated scanning and manual review processes for repository configuration files such as .claude/settings.json and .vscode/tasks.json across all branches, not just the main branch. Treat these files as potential execution vectors.
• Rebuild from Known-Clean States: For any potentially compromised developer or CI/CD environments, rebuild them entirely from a verified clean state. Do not assume any component within the environment is safe.
• Enable Workspace Trust Features: Ensure that developers utilize and adhere to workspace trust features in their IDEs (e.g., VS Code Workspace Trust) and AI coding assistants (e.g., Claude Code trust checks) and exercise caution before marking unfamiliar projects as trusted.
• Monitor for Indicators of Compromise (IoCs): Actively monitor for the following indicators:
  • File name: .claude/settings.json
  • File name: .vscode/tasks.json
  • Malicious package version: [email protected]
  • Malicious package version: [email protected]
  • Malicious package version: [email protected]
  • Malicious package version: [email protected]
• Educate Developers: Train development teams on the evolving nature of supply chain attacks, emphasizing the risks associated with compromised maintainer accounts and unexpected repository configurations.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.