What the TanStack npm compromise tells us about software trust.

On May 11, someone published malicious versions of 42 TanStack packages to npm. If you ran npm install in the wrong six-minute window, the payload pulled your cloud keys, GitHub tokens, SSH keys, and npm credentials off the machine. Then it used the stolen npm tokens to republish other packages the victims maintained. A worm.
The payload isn't what catches our attention, actually. The interesting part is how it got there.

Nobody phished a maintainer or stole a password. The attacker exploited a misconfiguration in TanStack's CI/CD pipeline and published malware under TanStack's own trusted identity. From npm's side of the wire, these were legitimate releases, signed, and provenanced.

That should bother people more than it does. Most of the software supply chain still runs on the assumption that "it came from the real publisher" implies "it does what it claims." That assumption is getting harder to defend. CI/CD pipelines are sprawling, built from third-party parts, and each part is its own attack surface. And on top of that, AI is now writing code faster than anyone can review it. Code that lands in the same registries, behind the same trust signals, with the same install-time execution privileges.

Review and testing aren't going away, and shouldn't. But they were calibrated for a slower world, and they were never meant to carry this much weight on their own.

As a teaching moment for all of us, some of the available defenses that actually work against this class of attack are unglamorous and mostly known: pin dependencies by exact version and integrity hash, disable install scripts by default, treat CI runners as part of your project's attack surface and scope their secrets narrowly, audit pull_request_target and similar workflow triggers, and monitor your dependency graph for newly published versions and unusual install behavior.

TanStack will recover, but collectively, we need to ensure that the structural problem won't.