TanStack published a postmortem on the npm compromise that hit 42 of its packages, 84 malicious versions in all, as part of a wider wave across npm and PyPI. A pull_request_target workflow in a bundle-size check gave a fork repository privileges. That was used to poison the GitHub Actions cache. The poisoned cache ran inside the release workflow, where it minted an OpenID Connect (OIDC) token and published through the legitimate pipeline, with valid provenance. The payload harvested cloud, npm, GitHub, and secure shell (SSH) credentials from whatever installed it, and used the npm tokens to spread.
The timeline was good: about twenty minutes to detection, under two hours to deprecation, tarballs removed within five. It still did not help anyone who installed in that window.
I think this incident settles that provenance and trusted publishing verify where a build ran, not whether it was hijacked. These packages had a clean signature because the real pipeline built them. A consuming team cannot rely on the publisher's hygiene, which here was better than most.
So my view is that the controls have to live on the consuming side: a minimum release age before a version can be installed, lockfile changes reviewed like code, and continuous integration (CI) secrets scoped so that a compromised dependency finds nothing worth taking. Those work whatever happens upstream.
If one of your dependencies shipped a bad version at 2am, what on your side would have stopped it reaching a build?
Photo source: https://photos.robertstowe.com/eclipse