Tailscale SSH Port Forwarding Carries Root Access Across a Tailnet

TL;DR

• Tailscale SSH is the embedded SSH server inside the Tailscale client: a device claims port 22 on its own Tailscale address, and one access rule decides which devices may open a session on it.
• A report called Tailworm, published on 25 October 2026 by Erica Windisch of Cyberdione Labs, describes eleven findings in five classes against Tailscale 1.104.2 and headscale 0.29.5, all reproduced in a lab between 22 and 24 October 2026.
• The first class covers Tailscale SSH itself: unix-socket forwarding runs as root inside tailscaled, so an ordinary approved session can dial docker.sock, /run/systemd/private or tailscaled.sock on the target.
• Per-pair access rules and hardware-bound device keys were the two controls that stopped the spread in testing, and the report measured a spread of under a second per hop without them.
• Tailscale's vice president of engineering says the company has the report, has found issues it is working to fix, is still working out which setups are affected, and is "not recommending that everyone disable Tailscale SSH"; no bulletin, CVE or fixed version existed when the report went public.
• The operator work runs to four checks: rewrite SSH rules as single source-to-destination pairs, turn forwarding off where the product allows it, remove app-connector permissions and serve forwards that point at a unix socket, and turn on node-key expiry.

When a company runs its servers on a mesh VPN, the access rule becomes the security boundary. Tailscale SSH authenticates a device over WireGuard with node keys, then applies the tailnet's access-control policy to the session. The Tailworm report argues that this design weakens security-in-depth: highly privileged processes absorb functions that OpenSSH isolates through privilege separation, while network security boundaries extend beyond what the products advertise.

What the Tailworm report tested

The report assesses released software inside a lab. Erica Windisch of Cyberdione Labs tested Tailscale client agent version 1.104.2 and headscale version 0.29.5, the self-hosted control server some networks run in place of the hosted service, between 22 and 24 October 2026. Every finding was reproduced on unmodified builds, with organisational identifiers redacted.

The audit covers the tailscaled daemon, its embedded SSH server, its Serve and Funnel surface, its DERP relay client, the headscale control server, the shared gliderssh library and the experimental conn25 app connector. The report groups eleven findings into five classes: Tailscale SSH socket forwarding; conn25 app-connector traffic sent beyond authorized destinations; unauthenticated headscale resource exhaustion that can crash the control server and block onboarding; an unbounded DERP-client read that exhausts agent memory; and Tailscale Serve failures that can expose the local administrative API or let some requests bypass per-mount authorization. Readers who want to check the work will find no public proof-of-concept code: the report says the kits went to Tailscale's security contact.

How an approved session reaches root on another server

Tailscale SSH works through device identity. When the feature is enabled, the client claims port 22 on the device's Tailscale address, and the connection is authenticated over WireGuard with node keys; an access control policy then decides whether the session is allowed. Tailscale SSH completes authentication from the device identity established by WireGuard. That design simplifies operation and makes a single policy mistake expensive.

The finding sits in what the SSH server does after the session opens. Unix-socket forwarding, the ssh -L and ssh -R options most administrators use for port tunnelling, is handled inside tailscaled, and tailscaled runs as root. Path checks and file operations therefore execute with root rights, and the report describes races plus a missing privilege drop that let an ordinary session replace, dial or delete privileged resources. A rule that admits an unprivileged account still produces a session that can reach docker.sock, /run/systemd/private or tailscaled.sock.

The second class widens the same idea beyond one host. The experimental conn25 app connector accepts the destinations a permitted user chooses, and network ACLs are never consulted for the destination that traffic actually reaches. On a cloud host that path ends at the metadata service; inside Kubernetes it ends at every cluster service. That is a policy-visibility problem in the same family as the socket problem: the thing being protected is reachable through a component that the rule did not describe.

The habit that makes this worth checking on a small estate is ordinary. Somebody enables ssh -L to reach a database console, or ssh -R to expose a local service to a colleague, and nobody revisits the rule that allowed the session afterwards. Each of those habits widens what one compromised laptop can do.

Why per-pair access rules stopped the spread

The report's wormable characterization depends on a specific chain of conditions: an attacker already controls a policy-permitted device, Tailscale SSH is enabled on reachable targets, and forwarding is available. Its evidence consists of the report's own lab reproductions on two named releases; independent reproduction and production evidence remain open questions in the cited record. The disclosure record also leaves remediation status unsettled: Tailscale acknowledged issues and was still determining which configurations were affected. The measurement is a lab result: one compromised device spread to every device the policy allowed, with no passwords, no stolen keys and no user action, at under a second per hop. Nobody has reported the same behaviour on a production network, and the report says as much.

Two structural limits held during the tests. The first is rule shape. Access rules written as single source-to-destination pairs, naming one device and one target, bounded the spread by themselves, because a compromised device could only reach the targets its own pair named. Rules that grant access by identity or by tag produced the wide graph. The second limit is key custody: device credentials bound to a TPM or a Secure Enclave prevented the identity theft that turns a temporary foothold into a persistent one, and Tailnet Lock stopped the final enrolment step even where the enrolment key itself had been captured.

What Tailscale says about the report

Tailscale has not published a bulletin for these findings. Its security bulletin page, read on 25 October 2026, lists TS-2026-013 from 21 October as the newest entry, and that one covers eight compromised eMudhra TLS intermediate certificates. The Hacker News reports no CVE identifier and no fixed version either, and the report's author describes the disclosure as reported but not coordinated.

The company has answered in public. Mike Shaver, Tailscale's vice president of engineering, wrote on Reddit that Tailscale had received the report, had already been looking at the same areas with outside security specialists, and had found issues it is working to fix. He said the company is still working out which setups are affected. He also said Tailscale is "not recommending that everyone disable Tailscale SSH."

Four checks an operator can run now

The mitigations that cost nothing are available today; apply each one. Start with the SSH rules: list every rule with an accept action, and rewrite each one as a pair that names one source device and one destination. Rules built on tags or on identity groups are the ones that produced the wide graph in the lab.

Then decide about forwarding. On the hosted service, forwarding can be switched off per rule. On headscale 0.29.5 the report says forwarding cannot be turned off at all, which turns every SSH grant on such a network into a grant of root on the target; that is the sharpest sentence in the whole document for anyone self-hosting the control plane. Where forwarding has to stay, check mode adds a login step in front of a session; the forwarding path remains capable of the privilege escalation described by the report.

The remaining checks sit in the same family. Remove app-connector permissions from devices that have no reason to hold them, and delete every tailscale serve forward that points at a unix socket. Turn on node-key expiry so a stolen key ages out, and enable automatic updates so the next bulletin lands without a project. If a device is compromised, delete it at the control plane; a revoked device cannot use a socket it can no longer reach.

The inventory question underneath all of this is the one worth writing down: which devices hold an SSH grant, which of those grants permit forwarding, and which devices can use an app connector. That list is short on most networks, and keeping it current gives you a policy that describes your estate. This inventory also informs alert design that explains an incident, where the value sits in the field somebody can act on.

Sources

Source: Tailworm — Security Assessment Report, Tailscale v1.104.2 and headscale v0.29.5 — tailworm.com, retrieved 2026-10-25 (testing window 2026-10-22 to 2026-10-24; all findings verified by reproduction in a lab on unmodified released software; five finding classes covering Tailscale SSH, app connectors, serve and funnel, the DERP client and headscale; unix-socket forwarding performs path checks and file operations as root, with races and a missing privilege drop letting an ordinary session replace, dial or delete privileged resources; docker.sock, /run/systemd/private and tailscaled.sock named as reachable targets; conn25 translates traffic to attacker-chosen destinations with no validation while network ACLs are never consulted for the true destination; on headscale v0.29.5 forwarding cannot be turned off at all; wormability measured under a second per hop with per-pair grants and hardware-bound credentials as the two limits that held; 111 raced dials to a kubelet socket stub, every accepted peer presenting uid=0 comm=tailscaled).

Source: Tailscale SSH — Tailscale documentation, tailscale.com/kb/1193/tailscale-ssh, last validated 5 January 2026, retrieved 2026-10-25 (Tailscale SSH lets Tailscale manage the authentication and authorization of SSH connections in a tailnet; enabling it claims port 22 for the Tailscale IP address and routes tailnet SSH traffic to an SSH server run by Tailscale; authentication and encryption use WireGuard and node keys; authorisation follows the access control policies in the tailnet).

Source: Security Bulletins — Tailscale, tailscale.com/security-bulletins, retrieved 2026-10-25 (newest entry TS-2026-013 of 21 October 2026 on eight compromised eMudhra TLS intermediate certificates and the distrust included in Tailscale v1.104.2 or later via Go 1.27.3; TS-2026-005 of 3 June 2026 records that Tailscale restricts Unix socket proxy targets to the root user, fixed in version 1.98.9).

Source: Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers — The Hacker News, 25 October 2026, retrieved 2026-10-25 (the Tailworm report by Erica Windisch of Cyberdione Labs, tested against Tailscale 1.104.2 and headscale 0.29.5 over three days in a lab; no security bulletin, no CVE identifier and no fixed version as of publication; Mike Shaver, vice president of engineering, wrote on Reddit that the company received the report, had been looking at the same areas with outside security specialists and found issues it is working to fix, that it is still working out which setups are affected, and that it is "not recommending that everyone disable Tailscale SSH"; recommended actions include single source-to-destination SSH rules, switching off SSH port forwarding where possible, removing app connector permissions, removing serve forwards that point at Unix sockets, enabling node-key expiry, enabling SSH check mode and automatic updates; the report describes tests on software with no attacks on real networks).

Source: the Tailworm report, Tailscale's SSH documentation and security bulletin list, and The Hacker News write-up, all retrieved 2026-10-25. Every version number, socket name, date, quote and measurement above traces to one of those pages; the ordering of the checks and the inventory questions are Netics analysis. Images are captures of the report, the documentation page and the bulletin list, plus three Netics editorial diagrams. Netics editorial, neticslabs.com.