Post

We at TanStack just had a major attack against our Router packages. We have a postmortem out now explaining what happened and how we mitigated the response: tanstack.com/blog/npm-sup... No other TanStack packages outside of the Router monorepo were impacted

tanstack.comPostmortem: TanStack npm supply-chain compromise | TanStack BlogOn 2026-05-11, an attacker chained a pull_request_target Pwn Request, GitHub Actions cache poisoning across the fork↔base trust boundary, and OIDC token extraction from runner memory to publish 84 mal...

40 reposts125 likes

That's an inaccurate assessment of what happened. None of our maintainers were compromised; nobody took direct action to incur this incident. Instead, a misconfiguration of our CI allowed this to happen fully autonomously.

Fair. I was more just using this as a humourous opportunity to remind everybody that we don't click on links, we don't think about clicking on links, and we certainly don't forward links to others for them to also click on.

I'm leaving for JSHeroes tomorrow, but maybe that's an opportunity to kickstart it in-person. I know @tkdodo.eu is gonna be there. Maybe someone else too? Regardless, I need someone who'd like to work with me and has enough expertise in how the project is set up to be able to push back /

when I try to make it too strict. We need a good balance between security and DX, otherwise people will just throw security out.

Thanks, I meant immune 😁 With the right tools and configurations you can prevent all known install-time attack vectors. As a result, the malware would be forced to rely on people running the software from the package, which is much less common than simply having it in the dependency tree.

I appreciate the effort into avoiding security theater BTW, please do keep pointing these out when needed. This is the rare situation where I actually stand by my claim of immunity under specific circumstances.

Actions are unsecurable by design. We need to do our best to harden them but add one more layer. We need that staged publishing github/npm announced they wanted to build (months ago)

This post mortem reads like it was written nearly entirely by Claude. It’s constantly repeating itself, and I feel like parts of it don’t make sense. It melodramatically insists that the attack isn’t novel three different times.

Like, inside the entirely redundant “Why none alone is enough” section, Claude’s bullet point list of the ‘three’ vulnerabilities begins, “1. pull_request_target alone is fine for trusted operations (e.g. comments, labeling).” I don’t see how it makes sense to present that as a vulnerability at all.

The ‘open questions’ section is baffling, too. Why are we reading about ‘Tanner’ having access to post-job logs? Is he not supposed to be the author? Why are we reading vague instructions to “cross-reference” the activity history of the malicious GitHub account?

A human wouldn’t write this because it takes effort to write words. You wouldn’t spend it writing this abundance of phrases that contribute literally nothing — phrases that, at best, restate the sentence immediately before them and that, at worst, compromise the cohesion of the text