Revoke That Token and Your Laptop Dies

Have you ever revoked a leaked token and felt that small wave of relief wash over you? The "phew, dodged that one" moment? Well, I'd like to ruin it for you.

This week, something happened in the npm ecosystem that I genuinely cannot stop thinking about. On Monday, attackers compromised 42 official TanStack packages, pushing out 84 poisoned versions in a six minute window. If that name doesn't mean much to you, here's the headline number: tanstack/react-router alone pulls over 12 million weekly downloads. So yes, a lot of machines.

But the scale isn't the interesting part. The interesting part is the punchline.

The booby trap

The malicious payload steals your GitHub token, your AWS credentials, your SSH keys, the usual horror show. Standard stuff for 2026. What's new is what happens next.

It plants a watcher on your machine. Every 60 seconds, that watcher quietly checks whether the stolen GitHub token still works. The moment it stops working, the moment you do the responsible thing and revoke it, the watcher triggers. And then it deletes your home directory.

Read that again. The correct, recommended, drilled-into-every-developer security response is the trigger. The npm token the attackers used was literally named "IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner." They're not even being subtle.

I find this darkly funny in a "I need to lie down" sort of way. Every security playbook I've ever read says revoke first, ask questions later. This attack weaponises that instinct.

The bit that should keep you up at night

Here's where it gets properly bleak. The TanStack team had 2FA on every account. They used OIDC trusted publishing, which is supposed to be the gold standard. The packages were signed with valid SLSA Build Level 3 provenance, the cryptographic seal of approval that's meant to prove a package is genuine.

All of it worked. All of it was bypassed.

How? The attacker didn't steal a password. They didn't phish anyone. They forked the TanStack repo, smuggled a malicious commit into the build pipeline through a cache poisoning trick, and let TanStack's own release system sign the poisoned packages as if they were the real thing. To npm, to every scanner, to every defender checking the signatures, the malicious versions looked 100% legitimate. Because, in the strictest technical sense, they were. They came from the real pipeline. They just contained code nobody at TanStack had written.

This is the first npm worm in history to ship with a valid certificate of authenticity. The same certificate we've all been told to trust.

So what do we do?

Honestly? We sit with the discomfort for a minute. Provenance isn't innocence. A signed package tells you where something was built. It doesn't tell you whether the thing being built was safe. We've spent years treating those two questions like they're the same. They aren't.

For our clients, and for ourselves, we're rethinking a few assumptions this week. If you install software, are you also auditing what your build pipeline runs? If you publish software, do you actually know who can trigger your release workflow? When was the last time anyone looked at a GitHub Actions file with the suspicious eye it deserves?

And if you installed a TanStack package on May 11, please don't revoke anything yet. Isolate the machine first, image it, then revoke. The attackers are counting on your reflexes.

Sometimes the most dangerous instruction in a security playbook is the one you've followed a hundred times without thinking.