The npm Worm Had Valid Provenance Signatures. That Was the Whole Problem.

On August 4, 2026, a maintainer account with commit access to the keyv and cacheable npm package families published a routine-looking version bump. Nothing about the release triggered an alarm. GitHub Actions provenance attestation ran, as it does on every publish, and stamped the package with a cryptographic signature proving it had been built from the account's own repository, on the account's own CI pipeline, by the account's own credentials. That signature was completely accurate. It was also completely useless, because the account itself had already been taken over, and for the next several hours npm quietly shipped credential-stealing malware to a dependency tree that touches more than two billion weekly installs — every poisoned version signed, verified, and provenance-clean the entire time.

By the time Wiz and Snyk had mapped the blast radius, the count stood at 444 packages and 2,234 poisoned versions, with a payload built to hunt specifically for AWS, Kubernetes, HashiCorp Vault, and GitHub tokens sitting in developer environments. Some poisoned packages went further than a normal postinstall script: they committed hook files for VS Code and Claude Code directly into source, which meant a plain git checkout of an affected repo — no npm install required — was enough to trigger the payload the next time an editor or an agent opened the folder. The incident write-ups from Wiz and Snyk are thorough on mechanism and indicators of compromise. What almost none of them say out loud is the harder conclusion: the specific defense the industry adopted after the last decade of npm attacks did nothing here, and the reason it did nothing is structural, not a bug to patch.

Provenance Was Built to Answer a Different Question

Package provenance — the SLSA-style attestation that ties a published artifact back to the exact source commit and CI job that built it — became a serious industry standard after event-stream in 2018 and ua-parser-js in 2021, two attacks where a malicious actor slipped code into a popular package and nobody could prove after the fact what had actually shipped versus what the source repo claimed to contain. Provenance closes that specific gap. It answers "did this artifact come from the account and pipeline it claims to"? It cannot answer, and was never designed to answer, "is the account itself still controlled by the person the ecosystem trusts?"

That distinction sounds pedantic until you watch it play out at 2 billion weekly installs. The keyv worm didn't forge a signature or exploit a gap in the attestation pipeline. It didn't need to. The attacker had valid credentials to a legitimate maintainer account, so every artifact it published was, by definition, exactly what provenance promises to verify — a build that genuinely came from that account's repository and that account's CI. The entire security proposition of provenance signing rests on an assumption that sits one layer below the artifact: that account compromise is somebody else's problem to solve. In August 2026, for a maintainer account sitting at the root of a two-billion-install dependency tree, it wasn't.

The Trust Boundary Was Never the Artifact

This is the argument the incident reports stop short of making, and it's the one worth sitting with: the entire post-2018 supply-chain-security consensus — SLSA levels, sigstore, provenance badges, "verified publisher" checkmarks — was built around securing the artifact-to-source link, because that was the failure mode of the attacks that prompted it. event-stream was a malicious contributor slipping code past review. ua-parser-js was a hijacked npm account publishing directly, before provenance existed to even flag the gap. The tooling response to both incidents assumed the fix was "prove what shipped matches what was reviewed." Nobody built the equivalent rigor around "prove the account publishing this is still held by the person the ecosystem trusts," because that's a harder, messier, more human problem — it touches credential hygiene, phishing resistance, session-token lifetimes, and the reality that a maintainer with commit rights to critical infrastructure is often a single person running 2FA on a phone that gets the same phishing emails as everyone else's.

Treating provenance as the finished solution let the industry stop asking the harder question. A "verified provenance" badge reads, to almost every engineer evaluating a dependency, as "this is safe" — not as the much narrower and more accurate "this artifact matches its claimed source, assuming the claimed source is still trustworthy." That gap between what the badge signals and what it actually proves is exactly wide enough for an attacker with a stolen session token to walk through, and on August 4 one did.

What the Incident Reports Got Right — and Where They Stopped

Wiz's and Snyk's technical breakdowns of the keyv worm are genuinely good engineering writing: clear indicator-of-compromise lists, exact package and version ranges, payload behavior, remediation steps. That work matters and every team with keyv, cacheable, or their transitive dependents in a lockfile should be reading it directly rather than a summary of it. But incident reports optimize for "how do I clean this up" and "how do I detect the next one technically," not for "what does this mean about the assumption my security posture was built on." Neither framing is wrong. Both stop one level short of the uncomfortable structural point: the attacks the industry hardened against in 2018–2023 are recurring in 2026, wearing a provenance badge that was specifically supposed to prevent them.

The pattern rhymes with what happened to the xz-utils maintainer — a different mechanism, same underlying category error. That incident exposed how much critical infrastructure runs on unpaid, under-resourced individual maintainers whose burnout becomes an attack surface. This one exposes that even a well-resourced, actively maintained package family is one compromised credential away from shipping signed malware to two billion installs a week, because the signature was never checking the thing that actually failed.

So Actually, the Fix Isn't a Better Badge

The instinct after an incident like this is to ask what the next layer of cryptographic attestation should be — sign the signer, attest the attestation, add another checkmark to the supply-chain dashboard. That instinct is exactly the one that produced the gap in the first place. Provenance is worth keeping; it closes a real problem. But it was never going to close this one, and no amount of additional artifact-level signing will, because the failure didn't happen at the artifact layer. It happened at the layer where a human's session got compromised and nobody downstream had a mechanism to notice that the human behind a trusted account had, functionally, stopped being that person for a few critical hours.

The organizations that come out of this better won't be the ones that add a fifth badge to their dependency dashboard. They'll be the ones that start treating maintainer-account security — hardware key enforcement, short-lived publish tokens, anomaly detection on publish behavior itself — as a supply-chain control with the same seriousness as the cryptography, instead of a soft HR-adjacent afterthought sitting outside the security team's actual scope. Until that shift happens, the industry will keep building better locks for a door that was never the one the attacker walked through.

The next worm won't need to break your provenance chain either. It'll just need someone's login.