Provenance attests the factory, not the code
Five poisoned @asyncapi npm versions shipped through the project's own release pipeline — every one with valid provenance. Attestations prove which workflow built a package, not that the inputs were clean.
On July 14, 2026, attackers published five poisoned versions across four @asyncapi npm packages — roughly 2 million weekly downloads between them — and every single one carried valid provenance. The compromise facts are corroborated independently by Microsoft's July 15 write-up, StepSecurity, and Socket: no npm token was stolen, no install scripts were used, and the malicious versions were republished within about ninety minutes of takedowns through the project's own GitHub Actions release pipeline via npm's OIDC trusted-publisher flow.
The attack path, per StepSecurity, is almost insultingly simple: push access to the repos' next branch. From there, the legitimate release workflow did exactly what it was designed to do — built what was on the branch and published it with a signed attestation. The attestation is technically true. The authorized workflow really did build those packages.
Sit with the uncomfortable part. Trusted publishing was the ecosystem's answer to stolen npm tokens, and here it worked precisely as designed — and that success is what signed the malware. The weakest link moved from publish tokens to branch-push credentials, and the attestation format has no field to express whether the commits feeding the build were legitimate. Provenance attests the factory. It says nothing about what was wheeled onto the factory floor.
Two heuristics died in one incident
The second casualty is the "no postinstall scripts, so it's safer" rule that many scanners — and many agent-driven security checks — still lean on. This loader fires at import time, the moment a build or CI job first requires the module. Install-time scanning sees a clean package; the payload waits for import.
Which brings this to my corner of the industry. An agent-driven dependency updater instructed to "only accept attested builds" would have waved all five versions through. So would an enterprise pipeline gating on npm provenance or SLSA attestations. At work, this stung directly: a client hardening exercise I was involved in had listed "require provenance on all npm dependencies" as a completed control, and I had signed off on it as meaningful. On July 17 I reread that line in the report and had to send the honest follow-up: the control we marked green would have passed this attack without a murmur. That email cost me some pride and the client a re-scoped backlog, and it was the correct trade.
One hedge on the payload itself: capability descriptions diverge by vendor. Most write-ups describe a multi-stage botnet loader dubbed "Miasma"; BleepingComputer's headline framed it as credential-stealing. Treat any specific capability list as vendor-reported analysis, not established fact. The mechanism — valid provenance, import-time execution, branch-level compromise — is the multiply-corroborated part, and it is the part that matters for your pipeline.
My rule coming out of this: provenance is an authentication signal, never an integrity signal, and no single signal gates an install. Attestations still earn their place — they kill the stolen-token class of attack dead. But they must be paired with controls that look at the code, not the certificate: version-diff review on update, behavioural or static scanning that runs at import semantics rather than install semantics, and a cooling-off delay so you are never the first fleet to execute a fresh version.
Steal this for your next platform review: add a 48-to-72-hour quarantine for newly published versions of high-blast-radius dependencies, attested or not, and require an automated diff summary before any agent or renovate-bot merges the bump. Then grep your security docs for the phrase "verified provenance" and check what each occurrence actually protects against. Anywhere it stands alone as an integrity control, you have the same green checkbox I had to retract.
A valid attestation proves the right factory built the package — not that the right code went in; gate on the certificate and the contents, or you have automated misplaced trust.
