Security Guides
One npm install Can Empty Your Credentials — Defending Against Supply-Chain Worms
ChainDrop poisoned 444 npm packages in under four hours in August 2026 — and shipped them with valid provenance. It harvests credentials at install time, then uses the stolen GitHub token to copy your private repos into public ones. What actually stops it.
Who this is for: anyone developing with npm or pnpm, keeping code on GitHub, or deploying from CI. It is based on public research from vendors and labs, and contains no exploitation steps or samples.
What happened (ChainDrop, August 2026)
4 Aug 2026
The GitHub account of a maintainer behind widely-used caching packages was compromised. The attacker triggered the projects' existing GitHub Actions release workflows to publish poisoned versions to npm.Within four hours
444 packages and 2,212 versions were poisoned, including packages whose combined weekly downloads exceed 500 million.On install
Install-time hooks harvested npm, GitHub, cloud (AWS/GCP/Azure), SSH keys, Kubernetes and CI/CD credentials — including, per published analysis, short-lived OIDC tokens scraped from CI runner memory.Then
Stolen credentials were used to republish every package the victim could publish — self-propagation — with the harvested secrets exfiltrated to public GitHub repositories created by the attacker.
The headline harm in this family: your private repos become public
Shai-Hulud-family worms use the stolen GitHub token to copy the victim's private repositories into public ones — names ending in -migration have been reported. GitHub was not broken. A token lifted from your laptop or your CI runner does this as a legitimate action, with your own privileges. Which is why "wait for the platform to fix it" is not a defense here.
Why it was not stopped
Add a dependency / install in CI
↓ preinstall / postinstall runs automatically
Arbitrary code on your machine or runner
↓ npm / GitHub / cloud / SSH / CI secrets collected
Legitimate actions with stolen tokens
private repos copied public / packages republished to spread
What did not help
- Signatures and provenance — issued legitimately under maintainer privileges, so verification passed
- "It's a big popular package" — the poisoned ones were exactly that
- Version pinning alone — you still pull it on a fresh install or the next bump
- Waiting for a platform fix — what was used were valid tokens and public APIs
What does help
- Install scripts disabled by default — the code never runs
- A cooldown before adopting releases — skips the publish-to-takedown window
- Short-lived, narrowly scoped tokens — limits what a theft is worth
- Egress restrictions on CI runners — closes the exfiltration path
Five things to do today
Search your own lockfile
Check whether any reported-poisoned version is present (for example keyv@6.0.0, flat-cache@6.1.24, file-entry-cache@11.1.6). A clean result is good news, but steps 2 onward are about the next wave, so keep going.
Turn off install scripts by default
Make CI use npm ci --ignore-scripts; for pnpm, set ignore-scripts=true in .npmrc and explicitly allow only the dependencies that genuinely need to build. This is the single highest-value change, because it removes the execution stage this attack depends on.
Let dependencies age before adopting them
Do not take a release the moment it lands — a 3-to-7 day cooldown is enough. When the window between publication and takedown is hours to days, as here, waiting alone avoids the whole thing. If you use automated update PRs, build that delay into the configuration.
Inventory your tokens; cut their lifetime and scope
Move GitHub personal access tokens from classic to fine-grained, shorten expiry, and limit them to the repositories that need them. Do not leave npm publish tokens sitting in CI. Handling of keys and secrets is covered in what is dangerous about .env and API keys and least privilege for SSH keys. The goal is to be robbed and have it not matter.
Audit your own GitHub account
Look for public repositories you did not create (names ending -migration, unfamiliar descriptions), GitHub Actions workflows you did not add, executable config dropped into .vscode/tasks.json or .claude/, and API keys or SSH keys you do not recognise. For machine-monitoring known vulnerabilities in your dependencies, see getting started with osv-scanner.
If you suspect infection, get the order right
Researchers make one point worth repeating: remove any resident component left on the machine (token-watcher scripts and similar) BEFORE you revoke the tokens. Reverse that order and the resident piece can react to the revocation. Roughly: (1) disconnect from the network, (2) remove persistence and suspicious files, (3) revoke and reissue in the order npm → GitHub → cloud → SSH → Kubernetes, (4) delete node_modules and caches and reinstall clean, (5) review your public repositories and package publish history. If you have no logs, the answer is "unknown", not "clean" — proceed as though you were compromised.
This site's view: a signature attests to origin, not to safety
Signing and provenance have been the headline supply-chain recommendation for years — and this campaign walked straight through them. That is not a surprise once stated plainly: a signature tells you who published something, not whether its contents are safe. A valid signature from a compromised account is valid and dangerous at the same time. So we treat provenance not as a control that makes you safe, but as a forensic tool for scoping impact after an incident. Prevention lives somewhere else entirely: do not execute other people's code at install time, and do not leave secrets where that code runs.
Sources
- Unit 42 (Palo Alto Networks) — ChainDrop: Inside a Self-Propagating npm Worm (propagation, harvested credentials, indicators)
- StepSecurity — ChainDrop npm Worm (detection indicators and remediation order)
- Elastic Security Labs — CHAINDROP worm hits 400+ npm packages
- SecurityWeek — Over 400 NPM Packages Infected in ChainDrop Supply Chain Attack (scale and sequence)
- Wiz — Shai-Hulud npm Supply Chain Attack (the private-to-public repository copying technique)
Read next
FAQ
QHow can running npm install steal my credentials?
Because packages may carry scripts that run automatically at install time (preinstall / postinstall). Adding a dependency is therefore equivalent to letting that code execute with your privileges. ChainDrop used exactly that to harvest npm, GitHub, cloud, SSH and CI/CD credentials.
QWhat does it mean that private repositories get published?
Worms in this family use the stolen GitHub token to copy the victim's private repositories into public ones — names ending in -migration have been reported. GitHub itself was not broken: a token taken from your machine or your CI performs the action with your own privileges. That is why waiting for a platform-side fix does not protect you.
QAren't signed packages with provenance safe?
That is precisely what was bypassed here. The attacker used maintainer privileges to trigger the project's existing release workflow, so poisoned versions shipped with valid provenance. A signature attests to who published something, not to whether its contents are safe. A valid signature from a compromised account is still a valid signature.
QWhat is the single most effective thing to do today?
Two things: disable install scripts by default (npm ci --ignore-scripts, or ignore-scripts=true for pnpm) and stop adopting brand-new releases immediately — let them age a few days. The first prevents the code from running at all; the second sidesteps the most dangerous window, the hours or days between publication and takedown.