ChainDrop: The npm Worm That Poisoned 444 Packages in Under Four Hours

On the morning of 4 August 2026, a single compromised developer account set off the fastest self-spreading software supply chain incident the open source ecosystem has seen. Within four hours, malicious code had inserted itself into 444 software packages across 2,212 published versions, jumping automatically from one company's build system to the next by stealing credentials along the way. This briefing explains what happened in plain terms, who is exposed, and the small number of decisions leadership needs to make this week.

Observed between 09:40 and 13:20 UTC on 4 August 2026. The campaign was still being cleaned up at the time of writing.

The Short Version for Leadership

An attacker took control of the GitHub account of a widely trusted open source maintainer. Rather than stealing a publishing key, they edited the source code of three of his projects and let the projects' own automated release systems do the publishing for them. The result: malicious software releases that were signed, attested and, by every automated integrity check available today, indistinguishable from legitimate ones.

The code that shipped was not a simple data stealer. It was a worm. Once it landed inside a company's build pipeline, it collected that company's own credentials and used them to publish itself into that company's packages — which then reached that company's customers. No further attacker involvement was needed at any step.

Why This One Matters More Than the Usual Package Incident

• Speed. From first poisoned release to 444 affected packages took under four hours. Human-paced incident response cannot keep up with credential-driven automation.
• Reach. The first three packages alone sit beneath roughly 450 million weekly downloads and are indirect dependencies of a very large share of the JavaScript ecosystem, including common linting and caching tooling. Most exposed organisations never chose these packages; they arrived several layers deep.
• Direction of travel. Within two hours the worm had moved out of public developer tooling and into corporate design systems and SDKs belonging to named enterprises — meaning private, commercial software supply chains were affected, not just hobby projects.
• Trust erosion. Because every malicious release carried a valid attestation, organisations that had invested in provenance verification received no warning at all.

How the Attack Worked

1. Account takeover. The attacker gained control of a maintainer's GitHub account and pushed changes directly to the main branch, bypassing review.
2. Legitimate machinery, malicious input. They tagged a release. The project's ordinary, untouched release automation built and published it — complete with a genuine signature.
3. Automatic execution on install. The package was configured to run a small script the moment anyone installed it. Nobody had to open or run the software.
4. A second stage arrives. That script downloaded a legitimate, widely used developer runtime directly from an official source, so the network activity looked entirely normal, then used it to run the real payload.
5. Credential harvesting. The payload swept the machine and the build environment for publishing tokens, cloud credentials, container platform access and secret store access.
6. Self-propagation. With those stolen credentials, it republished itself into the victim organisation's own packages — and the cycle restarted inside the next company.
7. Hidden command and control. Instead of a fixed attacker server that could be blocked or seized, the malware looked up its current destination from a public blockchain record. There is no single address to take down.

It also left itself behind. On developer laptops it planted start-up hooks in editor and AI-assistant configuration folders, so it would run again the next time a developer simply opened a project, and installed a watcher designed to trigger further activity at the moment the stolen access token is revoked.

Who Was Affected

Eight publisher accounts are known to have been used to push malicious releases during the campaign: jaredwray, thiennq, hubsyncdevops, abarreir-ornikar, sitthidet_arv, rooci, picsart-npm-service-owner and onereach.user.

The Eleven Original Carrier Packages

These are the first-tier compromises: packages that shipped the complete worm, published through the projects' own trusted release pipelines. If any of these versions appear anywhere in your dependency records, treat the environment as compromised.

Complete List of Affected Packages

All 444 packages and 2,212 versions identified during the observation window are listed below, including the eleven carriers and the 433 packages republished automatically by the worm. Many packages had long histories of older versions republished with the payload attached, which is why the version count is so much higher than the package count. Use the search box to check a specific name against your inventory, and audit transitive dependencies as well as direct ones.

Observed between 09:40 and 13:20 UTC on 4 August 2026. The list should be treated as a floor, not a ceiling — the campaign was ongoing at the time of publication.

What to Do This Week

Immediate — first 24 hours

• Search every dependency record across the organisation for the names and versions above, including indirect dependencies.
• Treat any match as a confirmed compromise of that machine or build job, not as a possibility to investigate later.
• Roll back and pin to the last known-good versions rather than relying on automatic version ranges.
• Remove the persistence watcher before rotating credentials on affected developer machines, since it is specifically designed to react to token revocation.

Within the week

• Rotate everything that was in reach: publishing tokens, cloud provider credentials, deployment keys, container platform service accounts, secret store access, personal access tokens and any credentials sitting in environment files.
• Review cloud audit logs for use of those credentials from unfamiliar locations during and after the exposure window.
• Audit your own published software for releases nobody on your team authorised — this is how second-wave victims discovered they had become distributors.
• Rebuild affected environments cleanly, with automatic install scripts disabled.

The Controls That Would Have Stopped It

• Turn off automatic install scripts in build pipelines. The entire attack depends on code executing during installation. Disable it by default and allow it only for the small number of dependencies that genuinely require it. This alone neutralises the whole class of attack.
• Adopt a minimum age for new dependency versions. Every malicious version here was consumed within minutes to hours of release, and the registry removed them within roughly two hours. A three to seven day cooling-off period on new versions is a cheap, high-yield control now supported natively by the major package managers.
• Control outbound traffic from build systems. Build agents should not be free to fetch arbitrary runtimes or contact arbitrary destinations. Reputation-based blocking is not enough here, because the download came from a well-known, legitimate source.
• Stop treating provenance as authorisation. Pair signature verification with change detection on the release itself: newly added install hooks, new files being shipped and edits to release tooling are all high-signal anomalies.
• Harden maintainer and developer accounts. Phishing-resistant multi-factor authentication, short-lived scoped tokens and mandatory review before code reaches a release branch would each, independently, have broken this chain.
• Govern AI assistant and editor configuration like code. This payload used those configuration folders for persistence. Inventory them, pin them, and alert on unexpected changes. Expect this technique to become routine.

What Boards Should Take From This

Three conclusions are worth carrying into your next risk discussion. First, third-party software risk is no longer only about the vendors you contract with — it now includes the thousands of unpaid open source components those vendors and your own teams pull in automatically. Second, the speed of automated propagation means detection and response windows must be measured in minutes, which requires continuous inventory rather than periodic audit. Third, cryptographic assurances answer the question “was this built from that source?” — they do not answer “should that source change have existed?”. That second question is a governance problem, and it is where the remaining exposure sits.

A continuously maintained, machine-readable inventory of every component in every application — including the ones you bought — is the difference between answering “are we exposed?” in ten minutes and answering it in ten days. In an incident that reached 444 packages in four hours, that gap is the entire risk.