Tailscale Patches SSH Flaws That Could Let Hacked Devices Gain Root Access on Other Servers

Tailscale has released version 1.104.4 to patch vulnerabilities in its built-in SSH server that could allow an attacker to gain root access on other servers. The flaws lie in how the Tailscale background process handles network connections, a task it performs with root privileges. For these exploits to work, an attacker must already have control over a device permitted to initiate an SSH session to the target server, with forwarding enabled in the network's access rules.

These issues were highlighted in a report called Tailworm, published by Erica Windisch of Cyberdione Labs days before Tailscale released the fix. Windisch tested the Tailscale client and the self-hosted headscale control server in a lab setting.

Tailscale's SSH server uses a device's identity and the network's policy file to determine who can connect, not a password or key. This means an attacker does not need stolen credentials; they just need a foothold on a device already trusted by the policy. The flaw does not enable an unauthenticated attacker to connect to any Tailscale SSH server, but only to those permitted by the policy file.

The problem lies in socket forwarding; when a permitted SSH session forwards a connection to a Unix socket on the server, the Tailscale process checks the path but then operates as root. An attacker could exploit this by swapping in a different path after the check, bypassing the safeguard meant to limit which sockets forwarding could reach.

In Windisch's tests, forwarding to the Docker control socket resulted in a root shell and access to the system's password file, /etc/shadow, without administrator rights.

Tailscale addressed these issues by updating the server to carry out forwarding as the logged-in user instead of as root and relying on the operating system's file permissions instead of its earlier path check. They also released bulletin 4, advising users to update to version 1.104.4 or later, disable SSH forwarding by setting TS_SSH_DISABLE_FORWARDING=1, and review SSH access rules to ensure only necessary users and devices have access.

Tailscale also recommends using SSH check mode, which requires users to sign in again before a session starts, for sensitive systems. However, Windisch's report indicates that even with the fix, a compromised device key remains valid until the device is deleted from the control plane. Tailscale's bulletin does not cover this scenario.

Moreover, on the self-hosted headscale control server, SSH forwarding is granted for every accepted session and cannot be turned off in the policy, making every SSH grant potentially equivalent to granting root access. The latest headscale release, version 0.29.5, does not fix these issues. Windisch called the chain "wormable," stating that a compromised device could spread to every allowed device within under a second per step, provided certain controls are not in place.

Tailscale rejected the worm description, stating that the findings describe lateral movement within the connections allowed by the policy file, not self-replicating malware.