ChainDrop has made an npm package compromise a warning about developer machines.

The self-propagating campaign poisoned 444 packages and more than 1,300 malicious releases after attackers took over the GitHub account tied to the Keyv caching library.

The affected packages represented more than two billion monthly installs. The operation spread through stolen npm publishing tokens and legitimate release channels.

It also moved beyond package installation: attackers added repository configuration that could run when a developer opened a project in VS Code or began a Claude Code session. A git clone and project open could therefore create exposure.

Abby Kearns said in a report shared with Cyber Security News (CSN) that the distinction was the attacker’s choice to bypass the install step that supply-chain controls watch.

Microsoft calls the campaign ChainDrop, while other researchers track it as Mini Shai-Hulud, following patterns seen in the recent Mini Shai-Hulud campaign.

The initial entry point has not been disclosed. Still, the incident shows how one compromised maintainer account can turn trusted publishing, automated workflows and developer tools into a distribution channel.

It also asks whether engineering teams inspect repositories only as source code, rather than content that can instruct local tools to act.

ChainDrop npm Worm

The attack began on August 4 with the compromise of the GitHub account behind Keyv and packages including cacheable, flat-cache and file-entry-cache.

Attackers used stolen credentials to publish altered releases, then harvested further publishing access to expand the infection.

Projects tracking newest major versions were at particular risk, while older pinned majors were protected.

The releases appeared trustworthy because they carried valid provenance attestations.

Four steps from a stolen account (Source - Medium) — Four steps from a stolen account (Source – Medium)

They were published through a GitHub Actions workflow configured as an npm trusted publisher, so records showed that an approved identity performed the release.

The problem was upstream: malicious source had entered the repository before the workflow ran, a lesson echoed by the GitHub Actions workflow weakness reported earlier this year.

That distinction matters because provenance can confirm a build’s origin, but cannot guarantee that the computer, account or repository that produced it was clean.

In this case, no signature was forged and no publishing pipeline was broken. The attackers abused access that the ecosystem was designed to trust.

For maintainers, the response was complex and time consuming. The Keyv maintainer wiped affected machines, disabled GitHub Actions and trusted publishing, withdrew compromised versions, removed malicious branches and tags, and reset impacted branches.

Teams should likewise revoke and rotate exposed credentials, review workflow permissions, and rebuild affected developer or CI environments from a known-clean state.

Repository Files Become an Execution Path

ChainDrop also placed two configuration files into reachable repositories across as many as 50 branches. One supplied a Claude Code SessionStart hook and the other defined a VS Code task to run when a folder opened.

Each could launch a dropper from the other tool’s directory, allowing execution without an npm install or build.

This approach falls outside the view of many dependency scanners. Those products commonly examine manifests and lockfiles to identify downloaded packages, not project settings that describe editor tasks or AI coding-tool behavior.

The risk is similar to a compromised automation action incident, where trusted development automation becomes the route to sensitive access.

VS Code Workspace Trust and Claude Code trust checks can stop automatic activity in an untrusted project. But the danger increases after a developer has already marked a familiar checkout as trusted.

Kearns advises teams to search every branch, not merely the main branch, for unexpected repository configuration and compare resolved versions with affected releases.

Organizations should treat repository-supplied configuration as executable content and add those paths to review, monitoring and incident-response checks.

They should inventory coding tools, examine files read at project open, restrict high-value tokens, and watch for earlier npm package compromises that may signal similar credential theft.

ChainDrop shows that a safe dependency tree alone no longer guarantees a safe developer workspace.

Indicators of compromise (IoCs):-

Type	Indicator	Description
File name	`.claude/settings.json`	Repository configuration file used to register a Claude Code SessionStart hook.
File name	`.vscode/tasks.json`	Repository configuration file used to create a VS Code task triggered when a folder opens.
Malicious package version	`keyv@6.0.0`	Identified malicious release on the newest major package line.
Malicious package version	`flat-cache@6.1.24`	Identified malicious release associated with the ChainDrop campaign.
Malicious package version	`file-entry-cache@11.1.6`	Identified malicious release associated with the ChainDrop campaign.
Malicious package version	`cacheable-request@13.0.20`	Identified malicious release that could affect projects resolving that package version.

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world

The post ChainDrop npm Worm Poisons 444 Packages Through GitHub Actions and Trusted Publishing appeared first on Cyber Security News.