DepWallThe keyv compromise shipped with a valid provenance attestation
Attackers poisoned the source repository and let the project's own GitHub Actions workflow sign the release. npm provenance did exactly what it promises, and the package was malicious anyway.
In August 2026 a maintainer account behind the keyv and cacheable package
families was compromised. Hundreds of packages were affected. The detail worth dwelling
on is not the scale — it is that the poisoned releases reached npm carrying a
valid, signed provenance attestation.
How that happens#
The attacker did not steal a publish token and push from a laptop. They pushed the payload to the source repository and let the project's own GitHub Actions workflow cut the release.
So the attestation is accurate. It says: this tarball was built by this workflow, from this commit, in this repository. Every one of those statements is true. npm provenance attests how a build ran. It does not, and cannot, attest that the source going into the build was honest.
Provenance is a claim about the pipeline, not about the code that entered it.
Why this matters for anything that checks attestations#
We have a signal that watches for provenance disappearing — a package that used to publish with attestations and suddenly stops is a strong account-takeover tell. It is a good signal and it works.
It also reads this attack as clean, and it is right to. There was no drop. The attestation was present, valid, and signed by the expected workflow.
That is not a bug in the signal. It is the boundary of what the mechanism can tell you, and any tool that treats "has valid provenance" as "is safe" inherits the boundary without noticing.
What caught it instead#
Delivery was ordinary: a preinstall hook that fetched a standalone Bun runtime and
ran a second stage, with the normal compiled output left intact so the package still
worked after install. The install-script signal fires on that shape regardless of what
the attestation says.
And once the tarball's digest was published in an advisory, the exact-hash check fires too — on bytes, with no opinion about who signed them. We keep that incident as a regression fixture precisely because it is the case where two of our own signals disagree: attestation says clean, and it is correct; the digest says malicious, and it is also correct.
The practical version#
- Provenance is worth having. It makes a whole class of laptop-published forgeries visible, and its absence where it used to exist is real evidence.
- Provenance is not a safety verdict. A compromised source repository produces perfectly attested malware.
- Something still has to read the package. The manifest, the install hooks, the bytes. Signing tells you where a thing came from, never what it does.
We publish this one as DW-2026-0009 in our
advisory feed, with the verdict our engine actually returns for it
recomputed each time the page is generated — including, elsewhere in that feed, the
incidents where the answer is that we do not catch it.