If you work within the modern JavaScript/TypeScript ecosystem, there is a very high chance you are using a TanStack library. Whether it’s the omnipresent TanStack Query (formerly React Query), Table, or the newer React Router, they are pretty much everywhere.
The attack
And May 11, 2026, definitely gave a lot of developers a stomachache.
For those who missed it, the TanStack ecosystem suffered a critical supply chain compromise (CVE-2026-45321). A threat actor managed to compromise TanStack’s CI/CD pipelines through a “Pwn Request” (cache poisoning via pull_request_target in GitHub Actions), successfully publishing 84 malicious versions across 42 discrete packages. While the main blast radius targeted @tanstack/react-router, the entire stack flashed red.
The worst part about this type of attack? The malicious code executes immediately the moment you or your build server runs an innocent npm install.
“Crisis Mode” Activated: What I did first
When a CVE like this lands on your lap, there’s no point in panicking; you need data. My priority was isolating the blast radius using three basic steps:
Timeline Cross-Referencing vs. CI/CD Logs
The very first thing I did was open the official TanStack post-mortem to grasp the exact exposure window (the timeline from when the malicious packages became available on npm to when they were officially pulled).
With those timestamps in hand, I went to our CI/CD server logs. I needed to answer one crucial question: “Did we run any automated build or deploy pipelines during this specific timeframe?”.
Fortunately, the result was negative. Our servers hadn’t touched npm while the attack was live. First line of defense: OK.
Local Dependency Auditing
Even with the server secure, the danger often lurks right next door: developer machines. Since we use packages like @tanstack/vue-query and @tanstack/query-core, there was a realistic risk that someone on the team could have run npm install locally and pulled a compromised version.
I immediately alerted the team to pause all local installations and initiated a dependency scan to ensure no one was stuck on an attacker-built version.
Leaving a Paper Trail (Governance)
Once the immediate risk was mitigated, I spent some time putting together a technical incident report. It might look like bureaucracy on the surface, but documenting the event chronology, what systems were validated, and logging a final status of “Not Compromised” is what separates a team that “got lucky” from a team with mature governance workflows.
How to make sure your environment is clean
If you think you might have been exposed over the past week, the path forward recommended by the TanStack team involves:
- Force the update: Move immediately to the patched versions they released right after the incident.
- Nuke local cache: Changing your
package.jsonisn’t enough. Delete yournode_modulesfolder, delete yourpackage-lock.json(or equivalent), and completely wipe your package manager cache (npm cache clean --force). - Host Inspection: The malicious script attempts to spread or harvest environment data. It’s well worth checking out the
Detectionsection in their official post-mortem to hunt down any anomalous processes or mutations within your.npmdirectory.
Full post-mortem can be read at: Postmortem: TanStack npm supply-chain compromise
Lessons for the future (An Architecture Perspective)
Incidents like this remind us that our software architecture is only as strong as the weakest link in our dependency supply chain.
Monitoring CVEs manually simply doesn’t scale. As a takeaway from this scare, our next step here is refining our CI/CD pipelines to bake in SCA (Software Composition Analysis) tools more aggressively, automatically breaking the build if a package-lock.json tries to sneak through with a compromised dependency.
What about you? How did you find out about this attack, and did you manage to run diagnostics on your project in time?
Comments