Tailscale SSH Flaw Exposes Root Access Risk Across Networks

"the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed."

What Erica Windisch reported in the Tailworm paper (Oct. 25, 2026)

Security researcher Erica Windisch of Cyberdione Labs published a report called Tailworm on October 25 outlining a set of 11 findings against Tailscale and headscale. Windisch tested Tailscale version 1.104.2 and headscale version 0.29.5 during three days of laboratory work. She wrote that a single compromised device on a Tailscale network, when Tailscale SSH is configured to allow port forwarding and when network access rules permit that device to reach others, can be used to obtain root access on reachable servers.

The report describes laboratory tests, not observed attacks on live networks. As of publication, Tailscale had not issued a security bulletin, assigned a CVE identifier, or released a fixed version.

How the SSH port-forwarding chain worked in the lab

Windisch's report focuses on how Tailscale SSH differs from a traditional SSH server: it identifies a connecting device and relies on a single access rule to permit a session rather than authenticating a user's password or key. That design means an attacker who already controls one device allowed by access rules can proceed without stolen passwords or keys.

In the lab Windisch demonstrated three exploit stages. First, a standard SSH port-forwarding session caused a root-level Tailscale process to connect to a system socket that only root should reach; the test gained root and read the system password file almost immediately. Second, a method replaced a root-owned socket with an attacker-owned socket, allowing direct root command execution against some services. Third, a race condition defeated a safety check on which files forwarding could touch; that chain captured a key used to enroll new devices and used it to join an attacker machine to the Tailnet as a trusted server — but only when the Tailnet did not have Tailnet Lock enabled. On networks with Tailnet Lock the enrollment secrets were captured in transit but the final enrollment step did not complete.

Other findings: app connectors, serve, DERP relay, and headscale

The SSH issue is one of 11 findings Windisch describes. She flagged app connector behavior in an experimental feature called conn25 as potentially impactful: a permitted user could send traffic to destinations security teams had not approved, including a cloud provider metadata service that can hand out server credentials. The report also examines the serve feature, the DERP relay between devices, and headscale implementation details. Windisch told The Hacker News the SSH privilege escalation "is worrying," and that the app connector finding "may be more impactful to some organizations."

No other researcher has publicly reproduced Windisch's findings, Tailscale has not confirmed the specific technical claims, and Windisch said she has not published the proof-of-concept code publicly; she provided that code to Tailscale's security contact.

Immediate mitigations Windisch and Tailscale recommend

• Review Tailscale SSH access rules and write them as single source-to-destination pairs naming one device and one target; remove broad identity- or tag-based rules. The report calls per-pair rules the one control that stopped spread in testing.
• Turn off SSH port forwarding where you can. On Tailscale's hosted service this is configurable per rule; on headscale 0.29.5 forwarding cannot be turned off, so the report says every SSH grant there should be treated as giving root on the target.
• Remove app connector permissions from devices that do not need them, and remove any tailscale serve forward that points at a Unix socket.
• Turn on node-key expiry so a stolen device key does not remain valid indefinitely.
• If a device is compromised, delete it at the control plane; reimaging does not revoke keys an attacker may already have copied.
• Tailscale additionally suggests enabling SSH check mode (which adds a login step before a session starts) and automatic updates; check mode does not fix the privilege escalation, it only adds another barrier.

What this means for hosted Tailscale customers, headscale operators, and security teams

• Hosted Tailscale customers: you can disable SSH port forwarding per access rule, which the report identifies as a key mitigant.
• Headscale operators (version 0.29.5): forwarding cannot be disabled, so the report advises treating any SSH grant as equivalent to root access on the target.
• Security teams: Windisch's testing showed access rules written as single source-to-destination pairs and device keys tied to hardware (TPM/Secure Enclave) limited spread; enabling node-key expiry and enforcing hardware-backed device keys are practical controls the report highlights.

Tailscale has publicly acknowledged receipt of the report; Mike Shaver, the company's vice president of engineering, wrote on Reddit that Tailscale had been looking at the same areas with outside specialists, had found issues it is working to fix, and was still determining which setups are affected. Shaver said the company was "not recommending that everyone disable Tailscale SSH." Windisch described her disclosure as "reported but not coordinated" but said she had given Tailscale a copy of the report and proof-of-concept code before the public post and had posted a file hash while advising users to disable Tailscale SSH.

The Tailworm report lays out a fast, lab-demonstrated path from one compromised device to broad privileged access where forwarding and permissive rules are present. With no patch, administrators must rely on configuration changes, control-plane deletions, and hardware-backed keys to blunt risk while waiting for vendor fixes and a formal bulletin.

Original report at The Hacker News