Four hours, four hundred packages, and valid provenance on every one
On 4 August 2026 a self-propagating worm entered npm through a compromised maintainer account. It pushed commits straight into source repositories, which triggered those projects’ own continuous integration pipelines to build and publish poisoned packages. Each infection steals the npm publishing token from wherever it lands, enumerates every package that token can write to, and publishes a poisoned version of each one. It reached more than 400 packages in under four hours, peaking at roughly one infected package per second, starting from keyv, cacheable, flat-cache and file-entry-cache.
What worked
Zscaler records nothing that npm, GitHub or anybody else did to detect, block or limit this while it was running.
What failed
Provenance, in the precise sense the ecosystem has spent years building. The poisoned packages carried "cryptographically valid SLSA Build Level 3 provenance" and valid trusted-publisher attestations, because they genuinely were built by the real project’s real pipeline from the real repository. Every link in the supply chain attestation was true. The commit at the start of it was not.
Zscaler states the conclusion plainly and it is the one to write down: "Do not treat SLSA/Sigstore provenance as proof of safety." Provenance answers where a package came from. It was never designed to answer whether the code is malicious, and an attacker who reaches the repository inherits the entire apparatus.
Then the automation. The release workflow "kicked in automatically", with no person between a pushed commit and a published package, which is what turned one compromised account into four hundred in four hours. And the tokens: every developer and every build runner that installed a poisoned version handed over its own publishing credentials, which is the mechanism that makes this a worm rather than an incident.
The number
4 hours
to reach more than 400 packages, at a peak of roughly one infected package published per second, every one of them carrying valid build provenance.
What to do instead
Put a delay between publish and consume. A release cooldown is the highest-value control against this whole class, because the worm ran its course in under four hours, and a policy of not installing anything published in the last day or two would have missed all of it. Zscaler recommends it and hardly anybody does it.
Then stop installing what you did not pin. Lockfiles applied strictly, npm ci rather than npm install, and a private registry proxy in front, so that a version published an hour ago cannot arrive in a build because a caret in a manifest allowed it to.
Then treat your build runner as a credential store, because that is what it is. Scoped, short-lived tokens instead of long-lived publishing credentials, restricted outbound network access from build environments, and pinned versions for every tool the build invokes. This spread because tokens were sitting where poisoned code could read them.
Then audit pull_request_target in your GitHub Actions workflows, which earlier waves of this campaign abused to steal a privileged token, and watch repositories that hold publish permissions for orphan commits and unexpected workflow files.
And change what provenance means inside your organisation. Treat it as an answer to where this came from, never as an answer to whether it is safe. If a policy anywhere says a signed package with valid attestation may skip review, this is the campaign that should change it.