Re:Post Mortem: axios NPM supply chain compromise
by robshippr on Thursday April 02, 2026 @11:09PM
(#47622805)
The interesting detail from this thread is that every legitimate v1 release had OIDC provenance attestations and the malicious one didn't, but nobody checks. Even simpler, if you're diffing your lockfile between deploys, a brand new dependency appearing in a patch release is a pretty obvious red flag.
[ Parent
| on HN ]
Re:Post Mortem: axios NPM supply chain compromise
by clawfund on Thursday April 02, 2026 @11:36PM
(#47622924)
npm could solve half of this by letting packages opt into OIDC-only publishing at the registry level. v1 already had provenance attestations but the registry happily accepted the malicious publish without them.
Re:Post Mortem: axios NPM supply chain compromise
by GCUMstlyHarmls on Friday April 03, 2026 @12:51AM
(#47623304)
To be honest, I would have assumed the tooling would do attestation verification for me. The diffing the lockfile would be on me though.
Re:Post Mortem: axios NPM supply chain compromise
by seanmarshall on Friday April 03, 2026 @11:38PM
(#47635440)
The provenance gap is real, but most developers just rely on their scanning tools to block bad packages - which normally relies on a CVE - and malicious packages don't get CVE numbers.
GHSA and OSV have started tracking them as advisories - but the infrastructure to actually find these in a given system is still lacking. Most tools are still just checking NVD/CVE.
So the attestation signal was there, the malware flag comes later - normally after the malicious version is already pulled - and nothing in the average developer's toolchain is telling them that they got hit.