TanStack npm packages breached

JavaScript package registries are supposed to save developers time. But they also concentrate trust — and that trust just got used against people. On May 11, 2026, attackers pushed malicious versions of 42 official `@tanstack/*` packages to npm, including router libraries used across a huge chunk of the React world. The ugly part is not just that the packages were poisoned. It’s that they were published through TanStack’s legitimate GitHub Actions trusted-publisher setup, which made the releases look real. ### What actually got hit? The compromised set covered 84 package artifacts across 42 TanStack packages, with two bad versions per package published in a burst between about 19:20 and 19:26 UTC on May 11. High-profile packages included `@tanstack/react-router`, `@tanstack/router-core`, and related router tooling. One of them pulls more than 12 million weekly downloads, so this was not some obscure corner of npm. (socket.dev) ### How did the malware get in? The attacker didn’t just slip code into a normal release. The published packages added a hidden `optionalDependencies` entry pointing to `@tanstack/setup`, fetched from a GitHub commit rather than the normal registry path. That extra package carried the malicious logic. TanStack’s own incident thread flagged the fingerprint as a `package.json` entry resolving to a specific orphan commit pushed to a fork, which helped hide it from casual review. (advisories.gitlab.com) ### Why is the trusted publisher angle so bad? Because this was the “real badge, wrong person” version of a supply-chain attack. The npm publishes were authenticated through TanStack Router’s legitimate GitHub Actions OIDC trusted-publisher binding. But the workflow itself had been set up in a way the attacker could abuse. GitLab’s advisory says the chain involved a `pull_request_target` misconfiguration, GitHub Actions cache poisoning across the fork-to-base boundary, and then extracting the OIDC token from the runner’s memory to publish malware under a trusted identity. (github.com) ### What was the malware trying to steal? Build-system secrets, basically. Multiple writeups say the payload targeted GitHub tokens, cloud credentials, SSH keys, and other secrets exposed inside CI environments. This campaign also had worm-like behavior in the broader ecosystem — researchers tied the same wave to compromises affecting Mistral AI, UiPath, OpenSearch, and others across npm and PyPI. Some reports also describe destructive code that could wipe files on an infected host, though the TanStack incident itself is most clearly documented as credential theft and propagation. (advisories.gitlab.com) ### Why does this feel different from normal npm scares? Most developers know the classic package-registry risks — typo packages, abandoned maintainers, leaked passwords. This one is nastier because the attacker abused the release automation that defenders have been told to trust. Even provenance signals can get muddy here. One analysis of the wider campaign says some malicious packages carried valid-looking SLSA provenance because the attacker was operating through the authentic publishing path. (advisories.gitlab.com) That means “signed” or “trusted publisher” no longer ends the conversation. ### What should teams do right now? First, identify whether any affected TanStack versions were installed on or after May 11. Then rotate anything your CI runners could access — GitHub tokens, npm tokens, cloud keys, SSH material, the lot. TanStack maintainers and security researchers also point to checking `package.json` for the malicious `@tanstack/setup` GitHub dependency fingerprint. More broadly, this is a push toward short-lived credentials, isolated runners, tighter cache boundaries, and treating CI as a hostile environment once a dependency compromise is suspected. (orca.security) ### So what’s the real lesson? The lesson is not “npm is bad.” It’s that modern package security now lives or dies in CI. If attackers can hop the trust boundary inside your build pipeline, they don’t need to fake being you — they can briefly become you. That’s why this TanStack breach matters beyond TanStack. It’s a preview of where supply-chain attacks are going next. (advisories.gitlab.com) (github.com)