Everyone already knows they should perform due diligence on a new vendor when it needs privileged access to your business. But if you don’t have similarly strong controls on your software supply chain, that’s just like partnering with hundreds of new vendors with no vetting… and likely not even knowing those vendors’ names.
— David Parker, Chief Research and Development Officer at Novacoast
At 9:00 a.m. UTC on August 4, 2026, someone published a routine-looking update to a Node.js caching library. Version 6.0.0 of keyv. Nothing about it looked wrong.
Four hours later, roughly 2,200 malicious package versions were live on npm, across at least a dozen organizations that had never heard of each other — some carrying valid cryptographic provenance attestations. That’s the ChainDrop supply chain attack. What should worry you isn’t the malware. It’s that controls the industry spent two years building — provenance verification, SLSA attestation, dependency scanning — looked at this and waved it through.
Key Takeaways for Security Leaders
- Scope: 400 to 1,300+ compromised npm packages, roughly 2 billion monthly downloads
- Root cause: one compromised maintainer’s GitHub credentials — not a software vulnerability
- Novel techniques: Ethereum smart contract for C2 resolution; .claude and .vscode configs as persistence
- Anti-IR design: a token-revocation kill switch and 24-hour self-destruct, aimed at standard IR playbooks
- No CVE exists for ChainDrop — it’s tracked as a campaign, not a vulnerability
- Biggest lesson: valid provenance proved the workflow built the package — not that the workflow was trustworthy
What Is the ChainDrop Supply Chain Attack?
ChainDrop is a self-propagating worm that spread through npm on August 4, 2026, starting from one compromised maintainer account and using stolen credentials to republish itself into hundreds of unrelated packages within hours. It is at least the fifth wave in the Shai-Hulud lineage, active since September 2025 — and the family’s source has been public since May 2026, so this may be a copycat.
For CISOs, the pattern matters more than the attribution: attacks on the open-source publishing ecosystem are now recurring, escalating, and reproducible by anyone willing to read the source.
ChainDrop Attack Timeline
09:00 UTC, August 4, 2026 — The first malicious release, keyv@6.0.0, goes live, published with the legitimate credentials of the maintainer behind Keyv and Cacheable.
09:38–13:20 UTC — Using credentials harvested from the first infections, the worm publishes roughly 433 more packages across 2,201 versions, spanning at least a dozen unrelated organizations — jumping scopes every two to seven minutes, per Semgrep. Here it stops being one vendor’s bad day and becomes an ecosystem event.
Within 24 hours — Microsoft, StepSecurity, Aikido, Unit 42, Sonatype, and Elastic publish analyses.
Why the Package Counts Don’t Match
| Source | Packages reported |
| StepSecurity | 444 |
| Integrity360 | 452 |
| Aikido | 868 |
| BleepingComputer (later tally) | 1,300+ |
None are wrong. They reflect different detection windows applied to a worm still republishing itself while researchers counted. If your IR playbook assumes one authoritative scope figure exists in the first hours, it won’t.
How Does ChainDrop Work? The Full Attack Chain
Initial Access and Execution
The attacker took the maintainer’s GitHub account through credential theft, not an exploit — an identity compromise from the first move.
Malicious releases added an npm preinstall hook launching setup.mjs, which executed an obfuscated JavaScript payload built on Bun. Timing is the point: npm runs preinstall scripts before installation completes, so the payload fired on developer machines and CI runners before any scanner saw the code.
Defense Evasion: Different Behavior, Different Environment
The malware profiled its environment first. On Russian-language systems it exited. On developer workstations it detached to keep running after installation. In CI/CD it stayed attached to the active job to reach workflow secrets and OIDC publishing permissions — deliberate, because CI holds the publishing credentials.
Credential Access: Active Enumeration, Not Just Scraping
The payload pulled credentials from local files, shell history, environment variables, and live GitHub Actions runner memory — then authenticated with what it found against npm, GitHub, AWS, Kubernetes, and HashiCorp Vault, enumerating whatever those identities reached.
Command and Control: A C2 Domain You Can’t Blocklist
Instead of hardcoding a C2 domain, the malware queried an Ethereum smart contract for the active one — letting the operator rotate infrastructure without touching the malware or tripping blocklists. Stolen data was compressed and encrypted (AES-256-GCM/RSA-4096) before exfiltration. If that failed, the malware created public GitHub repositories tagged “Shai-Hulud: Here We Go Again.”
Persistence: Your AI Coding Assistant Is Now an Attack Surface
Using stolen GitHub credentials, the payload injected files into .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, and .vscode/setup.mjs. Most dependency scanners don’t look there. A developer opening an infected repository in Claude or VS Code — weeks after the poisoned package was removed and closed out — can re-trigger the payload. This route survives the cleanup most teams consider complete.
Worm Propagation: How One Account Became 2,200 Versions
Every recovered npm publishing token was checked for write permissions and 2FA bypass. Given valid access, the payload downloaded the package’s latest tarball, inserted itself, bumped the patch version, and republished — all without a source commit, pull request, or tag, which is why the releases looked like ordinary patch bumps.
Anti-Forensics: Malware That Anticipates Your Playbook
A token-revocation watcher triggered a destructive handler the moment a monitored credential was rotated — so the first move of IR could itself be the trigger. The malware also self-destructed after 24 hours, wiping local state. Remediation sequencing is adversarial terrain.
Who Was Affected by ChainDrop? Victims and Impact
Microsoft’s and Integrity360’s advisories name Deliveroo, Ornikar, OneReach, Picsart, Qlik, and ServiceTitan. StepSecurity references “more than a dozen” victims; Cyberchief puts the count at nine. None had any relationship to each other, or to the original maintainer, beyond an affected package somewhere in a dependency tree.
The Transitive Exposure Problem
Two of the earliest-compromised packages — flat-cache and file-entry-cache — sit deep inside common tooling, including ESLint. An organization could be fully exposed without ever installing a compromised package deliberately.
| “We don’t use that package” is not the same statement as “we’re not exposed to that package.” |
If your SBOM program doesn’t reach several layers deep, this is the exposure it will miss.
What Did ChainDrop Cost?
As of this writing, no named victim has disclosed a quantified financial impact — no breach-cost disclosure, no regulatory filing, no insurance claim figure.
Early estimates here are unreliable, and the real cost is rarely the incident itself. It’s the tail: credential rotation across every affected identity, rebuilding CI images and caches, re-auditing release pipelines, engineering time diverted for weeks. The honest board conversation centers on that tail, not a headline number.
The Reputational Damage Is Bigger Than the Victim List
The durable hit isn’t landing on Deliveroo or Qlik. It’s landing on provenance attestation as a control. SLSA-style provenance lets consumers verify a package was built by the workflow it claims. Here that was often literally true — the attestation was accurate, because the attacker had compromised the workflow rather than forging the paper trail. If you’ve told your board “we verify provenance,” this is a direct challenge to that claim.
ChainDrop Indicators of Compromise (IOCs)
Drawn primarily from Microsoft Threat Intelligence’s teardown.
| Type | Indicator |
| SHA-256 | 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668 — setup.mjs (npm tarball preinstall loader) |
| SHA-256 | fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1eb — setup.mjs (.claude/.vscode repository loader) |
| SHA-256 | 9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc — Math_*.js payload |
| C2 domain | npm-cache[.]com (active at time of analysis) |
| C2 domain | pypi-get[.]com (earlier candidate) |
| C2 domain | js-mirror[.]com (earlier candidate) |
| C2 URL | hxxps[:]//npm-cache[.]com:443/router |
| On-chain C2 contract | 0xE1f2395ee43e45A1556EC6438a88c31B83493103 (selector 0x53ed5143) |
| Signed fallback marker | thebeautifulmarchoftime |
| File paths to hunt | .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, .vscode/setup.mjs |
Four Lessons That Outlive This Incident
- Provenance is necessary, not sufficient. It proves which workflow built a package, not that the workflow was trustworthy. Add a layer that assumes it can be compromised.
- Blockchain-resolved C2 is a preview, not a novelty. It sidesteps blocklists and threat-intel feeds because the domain isn’t fixed. Expect it to recur.
- AI coding assistant configs are a real persistence surface. Most dependency and secret scanners were never built to cover those paths. Extending your detection stack to hunt there is overdue.
- Your remediation playbook is now part of the threat model. Response sequencing must be designed assuming the adversary anticipated it.
ChainDrop Remediation: What CISOs and Security Teams Should Do
Immediate Containment
- Audit dependency trees, lockfiles, artifact repos, and CI caches against known-compromised lists.
- Hunt across all branches, not just main. Repository injection ignores the branch-protection assumptions source-code compromises respect.
- Check for unauthorized .claude and .vscode configuration changes across every repo.
Credential Response
- Rotate every potentially exposed credential — npm, GitHub, AWS, Kubernetes, Vault — from a clean environment.
- Sequence rotation with the kill switch in mind. Capture forensic evidence before triggering a rotation the malware may be watching.
Structural and Preventive Controls
- Adopt npm’s min-release-age and add a soak period before pipelines auto-consume new patch versions.
- Push for 2FA and hardware-key-backed publishing among maintainers you depend on. Treat account compromise as a first-class threat.
- Tighten GitHub Actions OIDC trusted-publisher configurations. Scope tokens narrowly; gate workflow changes affecting publishing.
- Extend SBOM and provenance programs with a control that doesn’t depend on the publishing workflow’s own attestations.
- Rebuild shared base images and golden CI runners after any confirmed exposure — poisoned caches persist invisibly in shared build infrastructure.
Governance and Board Reporting
- Fold open-source maintainer risk into third-party risk management. This didn’t originate with a vendor but behaved exactly like one.
- Brief your board on the pattern, not the incident. Wave five since September 2025 is sustained ecosystem risk, not a patch-and-move-on event.
The Seams Are the Target
ChainDrop didn’t succeed through a novel exploit. It succeeded by targeting the seams between identity, automated trust, and incident response process.
A stolen credential became a worm. A valid attestation became camouflage. The first move in incident response became a trigger. None of those are problems a single tool or patch resolves. They’re process and architecture questions — and they belong on your next security leadership agenda.