.jpg)
What happened in the ChainDrop attack?
Attackers hijacked one maintainer's GitHub account, and automation did the rest. On the morning of August 4 (UTC), the compromised account behind keyv, a caching library pulled roughly 150 million times a week, per StepSecurity's count, published a poisoned release. The attackers pushed malicious code to the main branch, so the project's own GitHub Actions pipeline built and signed it. The poisoned versions landed on npm with valid provenance.
Then the worm spread itself. StepSecurity counted 444 packages and 2,212 poisoned versions within four hours; by end of day, BleepingComputer's tally had passed 1,300 packages. Counts diverged between researchers as the worm kept republishing. It reached packages tied to Deliveroo, Qlik, Picsart, and ServiceTitan.
The mechanism, per Microsoft's teardown: a preinstall lifecycle hook runs the payload before installation completes, on developer laptops and CI runners alike, before any test or security check gets a look.
ChainDrop is at least the fifth wave in the Shai-Hulud lineage since September 2025. Researchers disagree on which branch it descends from, and the worm's source code has been public since May 2026, so this may be a copycat rather than the original operators.
Why do the stolen tokens matter more than the malware?
Removing the malware takes hours. The stolen credentials keep working until someone revokes every one of them. The payload hunted npm tokens, GitHub personal access tokens, SSH keys, cloud credentials in ~/.aws and ~/.config/gcloud, Kubernetes service accounts, Vault tokens, and secrets in environment variables. On GitHub Actions runners it dumped memory to grab the job's secrets.
npm began unpublishing within about two hours, but some poisoned versions stayed live as the latest tag late into the day. And the exfiltrated credentials did not come back with the takedowns.
Each stolen AWS key, Kubernetes token, and Vault secret now sits with an attacker and authenticates exactly as you would. The operators anticipated the cleanup: StepSecurity documented a token monitor that polls GitHub with the stolen credential every 60 seconds and fires an attacker payload the moment the token no longer works.
What can an attacker do with a valid cloud credential?
Whatever your IAM policies allow, and every log will record it as authorized activity. The playbook already exists. In the Codefinger campaign documented by Halcyon, attackers holding stolen AWS credentials ran CopyObject with SSE-C, server-side encryption using a key only they held, to overwrite S3 objects. AWS never stores that key, so nobody recovers the data. At the API layer the whole operation reads as normal.
A credential with delete permissions can erase native snapshots outright.
Cross-region replication doesn't answer this either, though not for the reason people assume. S3 won't propagate a malicious delete by default. What replication doesn't give you is a trust boundary: the replica sits inside the same IAM perimeter, carries no immutability, and a credential permitted to delete object versions in the source can generally do the same in the destination. Replication is a durability control, not a recovery control.
Blast radius: Everything a single compromised credential, account, or identity can read, change, or destroy. Recovery planning begins with mapping it honestly.
Do backups protect against stolen cloud credentials?
Backups beat the old attack pattern. A stolen valid credential goes after the recovery layer itself. To be fair to defenders, recovery really has improved. Sophos' State of Ransomware 2026 found ransom payment rates near record lows and 16% of victims back up and running inside a day, progress Sophos credits partly to sustained backup investment.
Attackers responded by moving upstream. The same research found 79% of ransomware attacks now begin with identity compromise. And here is the number that matters for ChainDrop: among victims breached through compromised credentials, 97% had MFA enabled in some form at the time of the attack. So the controls were in place, and the stolen credential worked anyway. Recovery costs still climbed to $1.7M on average.
Your recovery layer is part of what those stolen credentials can attack. Sophos research from early 2024 found attackers attempted to reach backups in 94% of ransomware cases and succeeded in 57% of those attempts, and victims with compromised backups paid ransoms at roughly double the rate. Better backups raised the stakes for attackers; a credential that can reach those backups removes the obstacle in one move.
There's also a timing problem. Attackers rarely act the day they get access, so credentials stolen on August 4 may go unused for days or weeks, and a team that later restores from a recent snapshot can restore the attacker's foothold along with the data.
When the stolen credentials do get used, the teams that recover cleanly will be the ones whose recovery copies live somewhere those credentials can't follow.
An attacker who owns your production credentials and can also reach your recovery copies turns your entire recovery plan into one large blast radius.
Engineering teams have reached the same conclusion on their own. Months before ChainDrop, an enterprise engineering team asked the Eon team to design their protection so a full production admin credential could not touch the recovery copies. They'd mapped their blast radius and didn't like the answer. A CIO evaluating the market told us the one scenario that keeps a separate recovery product in his stack is tenant hijacking. ChainDrop runs that scenario at ecosystem scale.
What should teams do this week?
Run the incident response first, then the architecture review it points to. The researchers tracking ChainDrop broadly agree on the immediate steps:
- Treat any machine or CI runner that installed an affected version as compromised, even after the package's removal.
- Remove the worm's persistence before rotating anything. StepSecurity found a token monitor that fires an attacker payload when you revoke the stolen GitHub token.
- Rotate every credential those environments could reach: npm tokens, GitHub PATs, SSH keys, cloud provider credentials, Kubernetes service accounts, Vault tokens, and anything in environment variables. Rotate from a clean machine.
- Audit repositories and cloud logs for unexpected activity, and rebuild affected runners. BleepingComputer's remediation guidance says it plainly: rebuild systems from safe backups or from scratch.
Rebuilding from safe backups assumes the backups stayed safe, which is exactly the assumption we'd push on. So after the rotation sprint, take each credential you rotated and list what it could have reached while valid. If recovery copies, snapshots, or vaults appear on that list, the next wave of this worm family already has a path to them. Plan on another wave. The lineage keeps producing them, and with the source code public, the next operator doesn't need to be the original crew.
Where Eon fits
Eon Data Protection exists for the failure mode ChainDrop exposes. Eon stores every recovery copy in an immutable, logically air-gapped vault outside your production IAM boundaries. The same credentials that reach your production workloads cannot reach the vault, so a stolen AWS key from a poisoned CI runner hits a boundary it cannot cross.
Eon connects through a single read-only role, with no agents or appliances to compromise. It watches for ransomware and tampering inside your databases, not only your files. When something changes your data maliciously, whether an attacker with stolen keys or a misbehaving production agent, Eon identifies the exact records touched and rolls them back, with recovery in minutes. SoFi cut recovery from a full day to minutes after moving to Eon.
For the fuller pattern of how attackers reach cloud data with valid credentials, read our cloud ransomware guide. For how detection and record-level rollback work in practice, see the ransomware protection overview.
FAQ
Was ChainDrop a ransomware attack?
No. ChainDrop stole credentials and secrets; no encryption or destruction event has surfaced in public reporting. The risk is what the stolen cloud credentials enable next. Codefinger showed attackers using previously stolen or leaked AWS keys to encrypt cloud data long after the keys left their owners' hands.
Which packages did ChainDrop compromise?
The attack began with keyv and cacheable, then spread to flat-cache, file-entry-cache, and more than a thousand downstream packages, including some maintained by Deliveroo, Qlik, Picsart, and ServiceTitan. Counts keep changing; check the StepSecurity and Aikido package lists for current indicators of compromise.
The poisoned packages had valid provenance signatures. How?
The attackers pushed code to the real repository and let the project's own GitHub Actions workflow build and sign the releases. An attestation answers which commit built this artifact. It has nothing to say about whether that commit should have existed.
If nothing broke in our environment, is rotating credentials enough?
Rotation revokes the tokens attackers already hold, and you should do it from a clean machine after removing the worm's persistence. It does not answer whether a future credential theft could reach your recovery copies. The only durable answer is structural: recovery copies somewhere a stolen credential can't go.
How is a logically air-gapped copy different from an immutable snapshot in my own account?
An immutable snapshot in your account resists modification but often stays visible and deletable to sufficiently privileged credentials in that account. A logically air-gapped copy lives outside your production IAM boundary entirely, so stolen production credentials cannot see or delete it.
