If your business runs any web application, has a developer on staff, or uses a software vendor who does - yesterday's attack on TanStack is something you need to understand before your next standup.
Here's what happened, in plain language.
What Is TanStack?
TanStack is a collection of open-source JavaScript libraries used by developers to build web apps. You've probably never heard the name. But if your business has a custom website, an internal dashboard, an e-commerce storefront, or a SaaS product built in the last five years, there's a reasonable chance a developer on your team - or at your agency - is using it.
TanStack's router package alone is downloaded millions of times per month. It's part of the plumbing behind a huge number of small business web applications.
What Happened on May 11th
Between 7:20 PM and 7:26 PM UTC on May 11th, an attacker published 84 malicious versions of 42 TanStack npm packages.
An npm package is a bundle of code that developers download and install as a building block for their projects. The attack worked by poisoning those building blocks.
The attacker had spent 24 hours quietly setting a trap. They created a fork (a copy) of the TanStack GitHub repository, hid a malicious payload inside it, and then exploited a known weakness in how GitHub handles code contributions from outside contributors - called the "Pwn Request" pattern. This let the attacker's code run inside TanStack's trusted build environment.
The result: when anyone ran "npm install" on a project using an affected TanStack package during that six-minute window, they weren't just installing code. They were running a credential harvester.
What the Malware Was Doing
The malicious code, once installed, immediately went looking for credentials on the machine where it ran. Specifically:
- AWS credentials (both from the machine itself and from AWS Secrets Manager)
- Google Cloud metadata
- Kubernetes service account tokens
- Vault tokens
- GitHub tokens stored in the CLI or in git configuration files
- npm tokens (from .npmrc files)
- SSH private keys
Everything it found was exfiltrated - sent out - over an encrypted messaging network called Session, which uses end-to-end encryption. That encryption means simply blocking the Session network's IP addresses is the only way to stop the data from leaving, because you can't inspect the contents.
There's one more detail worth noting: the malware self-propagated. After stealing your credentials, it used your npm account to republish your own packages with the same injection - spreading itself to anyone who installed your software.
How Fast Was It Caught?
Impressively fast. An external security researcher at a firm called StepSecurity spotted the suspicious packages within 20 minutes of publication. TanStack moved quickly to deprecate all affected versions and engaged npm security to remove the tarballs from the registry.
The attack window was narrow - roughly six minutes for the publishing, 20 minutes before detection. But npm installs happen constantly, in CI/CD pipelines running automatically around the clock. Six minutes is enough to catch a lot of machines.
TanStack has confirmed: no npm credentials were stolen. The npm publish workflow itself was not compromised. Only the packages listed in their tracking issue are affected. Clean families include @tanstack/query, @tanstack/table, @tanstack/form, @tanstack/virtual, and @tanstack/store.
What You Should Do Right Now
If you have a developer or use a development agency: Forward this article today. Ask them directly: did anyone run "npm install" on a project using TanStack packages on May 11th? The answer determines your next step.
If the answer is yes - any machine that ran npm install on an affected package on May 11th should be treated as potentially compromised. That means:
- Rotate AWS credentials immediately - from a different, clean machine
- Rotate GitHub tokens
- Rotate SSH keys
- Rotate any npm tokens
- Check CloudTrail logs for unexpected AWS API calls in the last 24 hours
Do not do this from the potentially compromised machine. Use a separate device.
If the answer is no: You're likely fine. This is still a good moment to ask your developer or agency what their dependency-monitoring process looks like. Tools like Socket.dev and StepSecurity's Harden-Runner can flag exactly this kind of supply-chain attack before the damage is done.
The Bigger Picture for Non-Technical Owners
You don't need to understand npm to understand this: the software your business runs is built from hundreds of small, third-party building blocks. Most of them are maintained by volunteers. And occasionally, attackers figure out how to poison those building blocks in ways that are nearly impossible for the end user to detect.
This is called a software supply chain attack. The 2020 SolarWinds hack was one. The 2021 Log4Shell vulnerability was one. The TanStack incident is smaller in scale, but identical in mechanism.
The defense isn't panic - it's process. Companies that had automated dependency scanning caught this before running anything. Companies that rotate credentials on a schedule limited the blast radius even if something ran.
The question to ask your developer today: what would we know if one of our dependencies was compromised?
If the answer is "not much," that's the thing to fix.
Danny Kowalski covers tools, technology, and digital security for small business owners at The Useful Daily. Sources: TanStack Postmortem | GitHub Security Advisory GHSA-g7cv-rxg3-hmpx | Tracking Issue