How The Latest TanStack Attack Added a “Dead Man’s Switch” to Supply Chain Malware!

Today’s post breaks down how attackers compromised TanStack’s release pipeline, poisoned GitHub Actions cache, and introduced a dangerous new concept into supply chain attacks: the “Dead Man’s Switch"

If your systems are hacked and you suspect a credential leak, what is the first step you’d take?

Yes, Correct. Revoke the tokens or Rotate credentials. .

And in most incidents, that thinking still works.

But the TanStack attack introduced something more dangerous:

A hostile feedback loop.

The malware doesn’t treat token revocation as a setback.

It treats it as a trigger.

The moment defenders revoke the stolen token — the malware retaliates.

---

📝 Background / Context

TanStack is one of the most widely used frontend ecosystems in modern web development. Its libraries power React applications, data fetching systems, state management workflows, frontend infrastructure used by millions of developers

Which means compromising TanStack doesn't compromise one company. It compromises every system wherever it's used — silently, automatically, at scale.

To manage releases and automate quality checks, TanStack uses GitHub Actions. When a developer opens a Pull Request, GitHub Actions runs automatically: compiling code, running tests, validating formatting. Standard practice for any serious open-source project. We shall see how the attacker abused this.

---

🔥 Attack Flow — Step by Step

1. Attacker forks TanStack Github repo > Creates malicious changes > Opens a Pull Request > This triggers GitHub Actions to run automated CI/CD workflows.
   

2. Here’s the flaw: instead of running in safe mode, this workflow ran in dangerous mode (i.e. the pull request ran with elevated permissions) > Attacker code runs inside Github Actions.
   

3. GitHub Actions heavily relies on reusable caches for performance > Attacker poisons the dependency cache with malicious content.
   

4. After a few days, TanStack maintainer performs a legitimate release > Release workflow restores poisoned cache > Malicious code executes inside trusted release runner.
   

5. GitHub runner process temporarily holds publishing tokens in memory > malicious code reads process memory > Extracts token > Within minutes, the attacker publishes malicious versions of official TanStack across 42 packages.
   

6. Millions of users, CI/CD pipelines download and execute > Malware steals GitHub tokens, SSH keys, npm credentials, cloud secrets, and CI tokens > Stolen credentials are then used to compromise more packages > creates worm-like supply-chain propagation.
   

7. The final blow: If a developer revokes a stolen GitHub token, the malware triggers the ‘Dead man’s Switch’ i.e. it deletes the user’s entire home directory!
   

---

This worm-like behaviour is not a new pattern. I’ve published an article “Shai-Hulud Attack” on this back in Sep’25. You can read more here if this interests you:

This is the story of the biggest hack in the NPM world (aka Shai-Hulud Attack)

---

💡 Key Insights

1. Most developers assume “unmerged code = harmless code.” This attack shatters that assumption. The malicious PR triggered an elevated-privilege workflow the moment it was opened. The code ran before any maintainer reviewed a single line.
   

2. If you think about it, to pull this off, the attackers did not compromise any maintainer accounts. No phishing. No account takeover. No zero-day exploit. They just piggybacked on the trusted release process itself. They did this so by chaining multiple flaws together: Github Actions abuse, Cache poisoning and Release pipeline trust. This is adversarial thinking at its best.

3. Its important to understand the flow here. Suppose you own a GitHub repository. Inside it is your codebase. Now another developer wants to fix a bug or add a feature to your code. But they should NOT directly edit your main branch. So they make changes separately and ask you to review them. That request is a PR (Pull Request). Now you want to review the code before merging. You want to automatically verify code compiles, tests pass, formatting issues etc. So you use GitHub Actions to run automatically when PR opens. So you say “When someone opens/modifies a PR, run this workflow.” This is where the challenge is.
   

4. Pull requests inherently involve untrusted code. That’s why GitHub provides two execution models:

   1. Restricted mode (pull_request): “Treat outsiders as untrusted and run with minimal privilege.”

   2. Trusted mode (pull_request_target): “Treat this as trusted and run with elevated privilege.”

   
   TanStack used the second one and accidentally allowed attacker-controlled code to execute.
   

5. The dead man's switch reframes standard incident response thinking. Traditionally, defenders assume actions like revoking credentials, cutting access, isolating systems are purely defensive recovery steps. Dead man’s switch malware breaks that assumption. It turns the defender’s own response into part of the attack chain. The attacker identified the most universal first step is to revoke credentials and weaponised that action. The implication is uncomfortable: Defenders must now anticipate not only attacker actions during compromise—but attacker reactions to incident response itself. The malware effectively says: “If you cut my access, I punish the host.”
   

6. But how does the attacker have access to do this after the token is revoked? Because the malicious package is running on the victim machine. Although it stole the token and is reusing it, remember that the demon is still running on the developer machine. A background script polls the victim’s GitHub token every 60 seconds. Waits. The moment it detects that the token is revoked, it deletes the user’s Home directory by executing the command “rm -rf ~/”.
   

7. The order of security operations matters when the attacker has anticipated your moves. In this case the correct order would be to remove the malicious package (and any traces of it) that are running on the system and then revoke the tokens.

8. The malware persists across reboots by hooking into your IDE. This is the detail that should concern anyone running AI coding tools. The malware establishes persistence hooks inside Claude Code and VS Code — meaning it survives a reboot and re-executes the credential stealer every time the IDE launches. The IDE becomes the persistence mechanism. As AI coding assistants become standard developer infrastructure, they also become a reliable persistence surface. That's a new angle that's going to show up in more attacks.

---

📌 Closing Thought

Modern attackers are no longer focused solely on endpoints.

They’re targeting:

• CI/CD pipelines

• Package managers

• Release workflows

• Developer environments

• Trust relationships between systems

Because compromising one trusted dependency is often more powerful than compromising thousands of machines individually.

And attacks like TanStack reveal something deeper:

The open source software supply chain is no longer just infrastructure.

It’s a force multiplier.

Once attackers compromise trust at the source, the downstream spread becomes automatic.

That’s what makes modern supply chain attacks so dangerous:

The victim unknowingly becomes the distribution mechanism.