Tailscale SSH Flaws: How One Device Can Reach Root

The Tailscale SSH flaws published on 25 October 2026 claim something uncomfortable: one hacked device on your tailnet can become root on other servers it is allowed to reach. Security researcher Erica Windisch of Cyberdione Labs calls the report “Tailworm”, and as of publication it had no CVE, no fixed version and no independent reproduction.

That mix of a serious claim and thin confirmation is why this story needs a calm read. Here is what is known, what is disputed, and what you can change today.

Key takeaways

• The attack needs Tailscale SSH with port forwarding allowed, plus one compromised device that your access rules let reach the target.
• Windisch tested Tailscale 1.104.2 and headscale 0.29.5 in a lab. Nothing suggests attacks on real networks.
• Tailscale has not confirmed the specific claims. Its VP of engineering said the company is already fixing related issues and is not recommending that everyone disable Tailscale SSH.
• The proof-of-concept code is private, so outsiders cannot yet verify it.

What do the Tailscale SSH flaws actually let an attacker do?

According to The Hacker News, Windisch described three routes to root, all built on Tailscale SSH’s port forwarding.

• Socket forwarding: ordinary SSH forwarding made the root-level Tailscale process connect to a root-only system socket. In the test, that gave root and a read of the system password file.
• Socket replacement: swapping a root-owned socket for one the attacker controls allowed direct root command execution against certain services.
• Race condition: a check-then-use timing gap defeated a file-access safety check. That chain captured an enrollment key so the attacker could join their own machine as a trusted server.

A socket is a local doorway that programs use to talk to each other. A root-only one is meant to stay shut to ordinary users.

The third chain worked end to end only on networks without Tailnet Lock. Where Tailnet Lock was on, the secrets were captured but the final step failed.

Is it really wormable?

Windisch calls it wormable: in her lab, a compromised device could spread to every device the rules allow, in under a second per step. Other researchers have publicly questioned that label, while some still call the root finding serious.

Two things slowed spread in her own tests: access rules written as single source-to-destination pairs, and device keys tied to hardware such as a TPM or Secure Enclave. My opinion: “wormable” is a lab description of a worst case, not a forecast. The real risk depends on how loosely your rules are written.

What has Tailscale said, and is there a patch?

There was no CVE, bulletin or fixed version at publication. Mike Shaver, Tailscale’s VP of engineering, said on Reddit that the company received the report, had already been reviewing the same areas with outside specialists, and had found issues it is working to fix. He said it is still working out which setups are affected.

The disclosure itself is disputed. Windisch called it “reported but not coordinated”, saying she sent the report and proof of concept to Tailscale’s security contact the Saturday before publishing. A Hacker News commenter called publishing without prior reporting irresponsible.

This is not Tailscale’s first SSH trouble this year. Advisory TS-2026-009, dated 13 July 2026, covered a leading-dash username that could open a root session on Linux. Fixes for that and related issues landed in version 1.98.9. Those are older, separate bugs, so being on a patched build does not clear you of the new claims.

How do you reduce your risk now?

You do not have to wait for a patch to shrink the blast radius. The mitigations in the report map to settings you control, and Tailscale documents SSH rules in its Tailscale SSH docs.

On headscale 0.29.5, port forwarding cannot be switched off, so treat every SSH grant as root on the target. If a device is compromised, delete it at the control plane. Reimaging does not revoke keys that were already copied.

What about the other findings?

The report lists 11 findings in total, covering app connectors, the serve feature, the DERP relay and headscale. Windisch argued that the experimental app connector issue, where a permitted user can reach unapproved destinations such as a cloud metadata service that can issue server credentials, may matter more to some organizations than the SSH one.

The pattern fits a wider theme. For context, see our pieces on finding vulnerabilities with Claude and the Node.js 24.22.1 security release: tooling that sits at the trust boundary keeps drawing scrutiny.

What happens next

Expect Tailscale to publish a security bulletin and a fixed version once it has confirmed which configurations are affected. Independent researchers will likely try to reproduce the findings, which would settle the wormable debate either way.

Until then, treat the claims as credible but unconfirmed, and tighten your rules rather than panic.

FAQ

Do I need to disable Tailscale SSH?

Tailscale says it is not recommending that everyone disable it. Windisch advised users to disable it. A middle path is to turn off port forwarding and tighten rules.

Can an outsider exploit this without access to my network?

Not directly. The attacker must already control one device that your rules allow to reach the target. The foothold could come from a web app bug, a poisoned package, phishing or stolen logins.

Is there a CVE or patch?

Not at publication on 25 October 2026. Tailscale says it is working on fixes, and it had not yet confirmed which setups are affected.

Next step: open your access rules this week, list every SSH grant with port forwarding on, and cut each to the narrowest source and destination you can.