Introduction

The ChainDrop npm supply chain attack began on August 4, 2026, and it is not the usual story of one poisoned package. Microsoft researchers tracked more than 400 packages across unrelated publishers, with the malware moving from one account to the next every two to seven minutes. SafeDep counted 1,684 poisoned versions across 420 package names and nine organizations. Aikido Security put the wider footprint at 868 packages across 1,381 versions, and researchers flagged over 500 GitHub repositories created the same day with a matching description, likely staging directories rather than confirmed victims.

The attack matters for two reasons. It is a worm: once it finds a valid npm publishing token, it republishes malicious versions of other packages on its own. And the poisoned releases carried valid provenance, because they were published through the legitimate GitHub Actions workflows of the compromised projects. If you install npm packages, this post walks through how the worm works and what to fix.

How the Worm Entered

The campaign started with [email protected], a single malicious release of the Keyv caching library. Keyv is popular infrastructure. Cache-manager sits on top of it, and both appear deep in dependency trees across the npm ecosystem.

The attacker used a preinstall script. When someone installs the package, node setup.mjs runs before the library is available, giving the payload a head start inside the build environment. According to SafeDep, the package also contained Math_Symbol.js and a compiled credential bundle of roughly 727,680 bytes. In the Keyv repository, the same commit that added the setup script carried a green verified badge from github-actions[bot], which makes the change look like an official release rather than an intrusion.

What the Payload Does

Once executed, the payload runs in two modes. On a developer workstation it detaches and keeps running in the background. In a CI/CD environment it stays attached, because the build job holds the secrets the attacker wants.

The payload collects credentials from several places:

• Shell profiles and environment variables, including GitHub CLI tokens
• Sensitive files such as .npmrc and private keys
• GitHub Actions runner memory during builds
• Cloud and infrastructure credentials for npm, GitHub, AWS, Kubernetes, and HashiCorp Vault

The data is gzip compressed, encrypted with AES-256-GCM, and sent over an HTTPS channel, with GitHub repositories used as fallback storage. The package also installs what SafeDep calls a credential-revocation watcher: it monitors for token rotation and runs attacker-controlled handlers when rotation happens. That matters when you plan your own response.

Self-Propagation: Why It Spread So Fast

The worm's propagation routine downloads every release available to the stolen account, copies the malware bundle into it, adds a loader, rewrites the lifecycle script, and republishes with a bumped patch version. Microsoft's write-up shows this happening with both a stolen npm token and a GitHub-issued token.

This is why SafeDep saw the worm move from one publishing account to another every two to seven minutes, covering nine organizations in a single morning. The registry removed some poisoned releases, but at the time of reporting, latest tags still pointed at malicious versions for most affected packages. Upgrading alone can leave you exposed.

Both SafeDep and Aikido agree that npm 12, which blocks unapproved lifecycle scripts by default, would stop the initial infection on most setups. Older npm clients and other install paths remain exposed.

Editor Hooks: Claude Code and VS Code

The Keyv repository also carried a second attack path that does not rely on npm at all. Files such as .claude/settings.json and .vscode/tasks.json add a session-start hook and a VS Code task that runs a setup script when the workspace opens. If a developer clones the poisoned repository and accepts the trust prompts, the editor itself executes the payload in a context where AI coding tools can capture sessions and tokens.

Both editors show a trust prompt before running project-provided configuration, so this path requires confirmation. That is a useful detail, because it gives you a place to stop the chain: say no to any workspace-trust prompt for a repository you do not fully control.

Checks and Mitigations

Here is what security teams can do now:

1. Check your lockfiles against the poisoned version lists from Microsoft's advisory and SafeDep's database, checking exact resolutions rather than just package names.
2. Treat any workstation or runner that ran a poisoned version as compromised. Do not simply update and move on, because rotating tokens while the revocation watcher is present runs attacker-controlled handlers.
3. Remove the credential-revocation watcher before rotation. Then rotate npm tokens, GitHub tokens, cloud keys, and any private keys from a clean machine.
4. Purge npm and yarn caches, and rebuild base images and CI caches that may have picked up the poisoned tarballs.
5. Review workflows with write access to package publishing, and confirm that OIDC and SLSA attestations are not the only line of trust. They sign the build, not the contents.

No public incident statement from npm, GitHub, or the Keyv maintainers existed when the research was published, so the full list of compromised accounts is still incomplete. That is an argument for following the SafeDep, Aikido, and Microsoft advisory feeds.

Frequently Asked Questions

• Is this attack the same as Shai-Hulud? Researchers link this activity to the Shai-Hulud family. SafeDep and Socket say the cluster shares components with it, and similar Claude Code hooks appeared in an April PyPI campaign.

• Does npm protect against install scripts? npm 12 blocks unapproved lifecycle scripts by default, which defuses the preinstall vector on that tool. Older clients and other install paths still allow them.

• Are my sandbox credentials at risk? The payload collects whatever it can reach. Dev credentials are often the most valuable because they sit where the release pipelines run.

• Why does this matter if I am not the maintainer? Because the worm walked through several unrelated packages. Even if you never install Keyv, a package you depend on may have been republished with the payload minutes earlier.

• Do I need to rotate tokens if my lockfile is clean? If your exact resolved versions do not match the poisoned list, your direct exposure is lower. Still, check audit logs for unexpected publish events on accounts that share the CI runners.

Key Takeaways

• A self-propagating npm supply chain affected over 400 packages across nine publishers in hours.
• The entry was a preinstall script with a 727KB credential bundle, plus Claude Code and VS Code hooks in the poisoned repository.
• Valid OIDC and SLSA provenance does not mean the code is safe; it only proves the platform it was published on.
• Rotating tokens before removing the watcher can trigger attacker-controlled handlers.
• Lockfiles and version pins are the reliable defense; the newest latest tags were still malicious after the purge started.

Conclusion

The ChainDrop event is a practical lesson: the npm ecosystem's trust in release pipelines is one token away from a worm. It moved faster than the security firms could map it, which means your incident response plan should not depend on a fix reaching you. Compare the lockfile, remove exposed storage from build machines that touched suspicious versions, and reconsider whether your publishing workflow can be resumed by anyone with a leaked token.

---

Sources: Microsoft Security Blog: ChainDrop supply chain compromise, The Hacker News: Keyv npm worm, BleepingComputer: Chain npm supply-chain attack