Unpatched Tailscale SSH flaws turn one compromised device into root on its neighbours

A lab assessment published on 25 October 2026 describes a chain of weaknesses in Tailscale SSH that, under specific conditions, lets an attacker who already controls one node on a tailnet obtain root on every other node that node is allowed to reach. There is no CVE, no security bulletin and no fixed release at the time of writing, which means defenders have to lean on configuration rather than patching.

What happened

The assessment tested Tailscale 1.104.2 and headscale 0.29.5, the self-hosted alternative to Tailscale's coordination service, over three days in a controlled lab. The work targeted released software only. No production networks were touched, and the proof-of-concept code has been shared privately with Tailscale rather than published.

The core problem sits in how Tailscale SSH handles port forwarding. Tailscale SSH does not authenticate a user with a password or key. It identifies the connecting device and lets a single access rule decide whether that device may open a session on the target. If the rule also allows port forwarding, three separate techniques were shown to escalate an ordinary session to root:

• Local Unix-socket forwarding. The Tailscale daemon runs as root. Forwarding a Unix socket through it made the daemon dial sockets that only root should be able to open, and the test read the system password file almost immediately without any administrator rights.
• Reverse socket forwarding. A root-owned socket was replaced with one controlled by the attacker, which allowed root-level command execution against certain services that trust that socket.
• A time-of-check / time-of-use race. A safety check intended to limit which file paths forwarding may touch was defeated by racing the moment the path is validated against the moment it is used.

In the lab, the third technique went further. It captured a key used to enrol new devices and used it to join an attacker-controlled machine to the tailnet as a trusted server. That final step only worked end to end on networks without Tailnet Lock. Where Tailnet Lock was enabled, the secrets were still captured in transit but the enrolment failed.

The report characterises the result as "wormable": one compromised device could spread to every peer the access rules permit, with no passwords, no stolen keys and no user interaction, in under a second per hop. That claim has drawn public pushback from some practitioners, while others consider the root-access finding serious on its own. It is worth being precise here. The spread was demonstrated in a lab, has not been reproduced by any third party, and Tailscale has not confirmed the specific technical claims.

The SSH chain is one of 11 findings in the same assessment. Others cover Tailscale app connectors, the serve feature, the DERP relay and headscale. One of them concerns the experimental conn25 app-connector mode, where a permitted user can reportedly route traffic to destinations the security team never approved, including a cloud provider's metadata endpoint, which hands out server credentials.

Tailscale's position

Tailscale has responded publicly. Its vice president of engineering said the company received the report, had already been reviewing the same code areas with outside specialists, and had found issues it is now fixing. The company is still working out which configurations are affected and is explicitly not recommending that everyone disable Tailscale SSH.

The disclosure itself has been described by its author as "reported but not coordinated". The report and proof-of-concept were sent to Tailscale's security contact before the public release, and a file hash of the report was posted publicly alongside advice to disable Tailscale SSH. This is not the first issue in this part of the product. Earlier in 2026 Tailscale fixed several SSH and socket-handling bugs, including one in which Unix-socket forwarding could reach a privileged socket, in version 1.98.9.

Why it matters

Tailscale is often deployed precisely to replace flat VPNs with identity-based, least-privilege access. The weak point described here is not the WireGuard tunnel but the trust model around SSH: the device is the identity, and forwarding runs inside a root process. That means an attacker's first foothold, obtained the usual way through a vulnerable web app, a poisoned package, phishing or stolen credentials, becomes the only hard part. Everything after that rides on the mesh's own access rules.

Two things stopped the chain in testing, and both are things an administrator controls today:

• Access rules written as single source-to-destination pairs, naming one device and one target, rather than broad grants by user identity or tag.
• Device keys bound to hardware such as a TPM or Secure Enclave, which cannot simply be copied off a compromised host.

Where the control plane is self-hosted, the margin is thinner. On Tailscale's hosted service, port forwarding can be switched off per rule. On headscale 0.29.5 it cannot be disabled at all, so every SSH grant there should be treated as equivalent to root on the target.

What to do now

Because there is no patch, the mitigations are configuration changes. Tailscale's own guidance and the report's recommendations overlap on most of them:

1. Rewrite SSH access rules as explicit pairs. Remove broad rules that grant SSH by identity or tag. Per-pair rules were the single control that contained the spread in testing.
2. Disable SSH port forwarding wherever possible. On the hosted service this is a per-rule setting. On headscale 0.29.5 it is not available, so assume root for every grant.
3. Strip app-connector permissions from devices that do not need them, and review any use of the experimental conn25 mode.
4. Remove any tailscale serve forward that points at a Unix socket.
5. Enable node-key expiry so a stolen device key does not remain valid indefinitely.
6. If a device is compromised, delete it at the control plane. Reimaging the machine does not revoke keys an attacker may already have copied.
7. Turn on SSH check mode and automatic updates. Check mode adds an authentication step before a session starts. It does not fix the privilege escalation, but it is one more barrier in front of it.

The broader lesson is that a mesh network's security is only as strong as the reachability its rules allow. The assumption that lateral movement is hard once a device is "inside" the tailnet does not hold here. Our penetration testing engagements are built around exactly this question: starting from one assumed-compromised host, how far can an attacker actually get through your access rules, forwarding settings and trust relationships before anything stops them? Knowing that answer before a real intruder does is what turns a configuration review into a defensible control.