Tailscale SSH turns one compromised device into root access across the mesh
On October 25, 2026, researcher Erica Windisch published Tailworm, a report showing that Tailscale SSH combined with port forwarding grants root access to every reachable server once a single device on the mesh is compromised. With no patch and no CVE so far, the immediate fix comes down to three settings: pairwise access rules, port forwarding off, and Tailnet Lock.
October 25, 2026. Researcher Erica Windisch of Cyberdione Labs publishes Tailworm, a report containing eleven findings about Tailscale’s network stack. October 25, 2026, the same day. Tailscale has released no security bulletin, no CVE, and no fixed version. October 25, 2026, again. VP of Engineering Mike Shaver responds on Reddit that the company is already looking at the same areas and working on fixes. The headline: Tailscale SSH, combined with port forwarding, lets an attacker who already controls a single device on the mesh gain root on every server the access rules let them reach — with no stolen password and no stolen key.
For a CISO who ditched the VPN fleet for a Tailscale mesh in the name of zero trust, the report is not a verdict against the tool. It is a lesson in what happens when a product moves security from the network into the access policy, then lets one privileged path cut through that policy.
Why Tailscale SSH is not normal SSH
Tailscale SSH does not behave like an ordinary SSH server. Instead of checking a user’s password or key, it identifies the device making the connection, and a single access rule decides whether that device may open an SSH session to a target. That inversion — authenticate the machine, not the person — is exactly what opens the gap: once an attacker holds an authorized device, there is nothing left to steal before moving forward.
Windisch tested Tailscale 1.104.2 and headscale 0.29.5 — the self-hosted control server some networks run instead of the hosted service — for three days in a lab. The report describes tests against software, not attacks on real networks.
Three escalation methods stand out. The first rides a plain SSH port forward: an ordinary session causes the root-level Tailscale process to connect to a system socket reserved for the superuser, and the test gained root and read the password file “almost immediately.” The second replaces a root-owned socket with the attacker’s, enabling direct root command execution against certain services. The third defeats a check meant to limit which files forwarding may touch by racing the system between the moment it validates a path and the moment it uses it — a classic time-of-check/time-of-use bug.
The common thread is that every path abuses Tailscale’s own trust model: because the daemon runs as root and the access rule trusts the device, the port-forwarding machinery becomes a bridge from “one compromised device” to “root everywhere the rules allow.”
A “wormable” report: what it claims, and what it does not
The most serious chain Windisch describes goes further: it captures a key used to enroll new devices and uses it to join an attacker-controlled machine to the network as a trusted server. That final step works end-to-end only on networks where Tailnet Lock is not enabled; where it is, the necessary secrets were captured in transit but the last step never completed.
The report calls the overall result “wormable”: in the lab, one compromised device could spread to every authorized device, with no password, no stolen key, and no user action, in under a second per step. “The mesh converts one ordinary foothold into fleet-wide privileged access at machine speed,” Windisch writes.
Two things held the spread back in testing: access rules written as unique source-to-destination pairs, which stopped it on their own, and device keys bound to hardware such as a TPM or Secure Enclave.
The finding deserves a careful reading. SSH is only one of the report’s eleven findings, which also cover app connectors, the serve feature, the DERP relay, and headscale. One of them, tucked inside the experimental conn25 app-connector feature, lets an authorized user send traffic to destinations the security team never approved — including a cloud provider’s metadata service, which can hand out server credentials. Windisch told The Hacker News that the app-connector finding “may be more impactful to some organizations” than the SSH escalation itself. No other researcher has publicly reproduced the results, Tailscale has not confirmed the specific technical claims, and the proof-of-concept code is not public: it was handed to the company’s security contact. Several researchers who read the report dispute the “wormable” label, while others consider the root-access finding serious.
A disclosure that split the room
Windisch’s publication itself triggered a debate over method. She described the disclosure as “reported but not coordinated” on Hacker News, and at least one commenter called publishing without first notifying Tailscale irresponsible.
Questioned by The Hacker News, Windisch says she did hand Tailscale a copy of the report and the proof-of-concept code before going public, sending them to the company’s security contact the prior Saturday. She also says she raised architectural concerns with the company’s CEO earlier, and had posted a file hash while advising users to disable Tailscale SSH.
On Tailscale’s side, Mike Shaver acknowledged on Reddit that the company had received the report, had already been examining the same areas with outside specialists, and had found issues it is working to fix. He added that the company is still working out which setups are affected and is “not recommending that everyone disable Tailscale SSH.”
The episode is the latest in a run of problems in the same part of Tailscale. Earlier in 2026, the company fixed several Tailscale SSH and server socket-handling flaws, including one where Unix socket forwarding could reach a privileged socket, in version 1.98.9.
What to do now
With no patch available, the remedies are configuration changes, and the report and Tailscale’s own guidance overlap on the essentials.
- Pairwise access rules. Rewrite your SSH rules as unique source-to-destination pairs — one named device to one named target — and remove broad rules that grant access by identity or tag.
- Port forwarding off. On the hosted service, turn forwarding off where it can be set per rule. On headscale 0.29.5, it cannot be disabled at all: every SSH grant must then be treated as root on the target.
- Tailnet Lock on. Enable it to break the final step of the chain — enrolling an attacker machine as a trusted server.
These three settings do not close the flaw; they make it unexploitable end-to-end until a fix ships.
For headscale users specifically, the absence of a per-rule forwarding toggle means the pairwise-rule rewrite is not optional — it is the only effective control until a patch lands.
Verdict
The report does not erase Tailscale’s value; it sharpens the condition of its security. If you run Tailscale SSH on the hosted service, harden now — source-to-destination pairs, port forwarding off, Tailnet Lock on — and shrink SSH grants to the minimum set of devices that genuinely need them. If you self-host headscale, your margin is thinner: as long as port forwarding cannot be disabled and no patch is published, treat every SSH rule as root access, and watch for the security bulletin Tailscale will eventually issue. The wider lesson holds for any zero trust mesh: security lives in the access policy, and a policy that lets a privileged path cross the control plane is no longer policy — it is an implementation detail.