ChainDrop npm Worm Poisons 444 Packages Through GitHub Actions and Trusted Publishing

A major npm supply-chain campaign tracked by Microsoft as ChainDrop has compromised 444 packages and more than 1,300 malicious releases, potentially affecting an ecosystem representing more than two billion monthly installs.

The campaign began with the compromise of the GitHub account associated with the Keyv caching library. Attackers used stolen credentials to publish malicious package versions and then harvested additional publishing access to propagate the compromise.

Researchers also identified a second execution path involving repository configuration files capable of triggering actions when developers opened projects in Visual Studio Code or started a Claude Code session.

Key Highlights

• Campaign: ChainDrop
• Also tracked by some researchers as Mini Shai-Hulud
• 444 npm packages compromised
• More than 1,300 malicious releases
• Potential ecosystem reach of more than 2 billion monthly installs
• Initial compromise involved the GitHub account behind Keyv
• Stolen npm publishing credentials were used for propagation
• GitHub Actions and npm trusted publishing were abused
• Malicious releases retained valid provenance attestations
• Repository configuration was used as an additional execution path
• .claude/settings.json was used for a Claude Code SessionStart hook
• .vscode/tasks.json was used to create a VS Code task triggered when a project opened
• Up to 50 branches reportedly contained the malicious repository configuration.

Initial Compromise

The campaign began on August 4, 2026, when attackers compromised the GitHub account associated with Keyv.

Packages associated with the affected project included:

• cacheable
• flat-cache
• file-entry-cache

Attackers used stolen credentials to publish altered versions and subsequently obtained additional publishing access, allowing the campaign to spread across the npm ecosystem.

The precise initial entry point used to compromise the maintainer account has not been disclosed.

Abuse of Trusted Publishing

One of the most important aspects of ChainDrop is that the malicious packages were released through legitimate GitHub Actions workflows configured as npm trusted publishers.

The releases therefore carried valid provenance attestations.

This means that package provenance could correctly indicate that the package was built and published through an approved workflow, while the underlying repository itself had already been compromised.

The attackers did not need to forge signatures or break the publishing pipeline.

Instead, they abused legitimate access that the software supply chain already trusted.

Why Provenance Was Not Enough

Software provenance can answer an important question:

"Where did this package come from?"

However, it does not necessarily answer:

"Was the source repository, maintainer account, or build environment trustworthy when the package was produced?"

In ChainDrop, malicious source code entered the repository before the trusted GitHub Actions workflow executed.

As a result, the release could legitimately pass provenance checks while still containing malicious code.

Self-Propagation

ChainDrop behaved as a self-propagating npm worm.

After gaining access to publishing credentials, the attackers used them to publish malicious versions of additional packages.

The campaign therefore transformed a single compromised maintainer account into a distribution mechanism capable of reaching numerous downstream projects.

Projects tracking the newest major versions were particularly exposed, while older pinned major versions were less affected.

Repository Configuration as an Execution Path

The campaign went beyond malicious npm packages.

Attackers inserted repository configuration files that could trigger execution when developers opened an affected project.

Two important files were identified:

.claude/settings.json.vscode/tasks.json

The first registered a Claude Code SessionStart hook, while the second defined a VS Code task triggered when a folder was opened.

These configurations could launch a dropper from the other tool's directory.

This means a developer could potentially be exposed simply by cloning a compromised repository and opening it in a trusted development environment—even without running npm install.

VS Code and Claude Code Risk

Traditional software-composition analysis generally focuses on:

• package.json
• Lockfiles
• Dependency versions
• npm package integrity

ChainDrop demonstrates that these controls may not be sufficient.

Repository configuration can also contain instructions capable of influencing local development tools.

Organizations should therefore treat configuration files consumed by development environments as potentially executable content.

Workspace Trust

VS Code Workspace Trust and Claude Code trust mechanisms can help prevent automatic execution when working with an untrusted project.

However, the risk increases when developers have already marked a repository or checkout as trusted.

A malicious configuration can therefore become more dangerous when introduced into a project that developers routinely work with.

Detection and Hunting Opportunities

Security teams should monitor for:

• Unexpected changes to package.json
• Unexpected package-version changes
• New npm releases from trusted maintainers
• Unusual GitHub Actions workflow modifications
• Unexpected publishing-token usage
• Changes to trusted-publisher configuration
• .claude/settings.json
• .vscode/tasks.json
• Unexpected Claude Code SessionStart hooks
• Unexpected VS Code tasks
• Repository configuration changes across branches
• Malicious branches or tags
• npm package releases outside normal maintainer activity
• Developer machines executing unexpected commands immediately after opening repositories
• Suspicious network activity from Node.js, VS Code or Claude Code processes
• Unexpected access to npm, GitHub or cloud credentials

Recommended Mitigations

1. Inventory all npm dependencies used across development and CI/CD environments.
2. Compare installed versions against the known affected package versions.
3. Search all Git branches, not only the default branch, for malicious configuration.
4. Review .claude/settings.json and .vscode/tasks.json.
5. Audit GitHub Actions workflows for unexpected changes.
6. Review npm trusted-publishing configuration.
7. Revoke and rotate exposed npm publishing tokens.
8. Rotate GitHub credentials associated with affected maintainers.
9. Review GitHub Actions permissions and secrets.
10. Rebuild affected developer and CI environments from known-clean images.
11. Pin critical dependencies to verified versions.
12. Require review for package and workflow changes.
13. Monitor npm publishing activity for unusual releases.
14. Restrict high-value credentials available to developer workstations.
15. Treat repository-supplied development-tool configuration as executable content.
16. Review coding-agent permissions and trust settings.

Threat Assessment

ChainDrop demonstrates an important evolution in software supply-chain attacks.

The attacker does not need to compromise every developer individually. A single trusted maintainer account can become a distribution point for malicious packages, while repository configuration can provide an additional route into developer environments.

The campaign also demonstrates that valid provenance does not automatically mean valid source integrity.

Conclusion

Organizations should expand software-supply-chain security beyond dependency scanning.

Security teams should monitor package releases, maintainer accounts, GitHub Actions, trusted publishing, repository configuration and developer-tool behavior as interconnected parts of the attack surface.

A clean dependency tree alone is no longer sufficient to guarantee a safe developer workspace.