Tailscale patches SSH flaws allowing root access via socket forwarding

Tailscale has released version 1.104.4 to address severe security flaws in its built-in SSH server that could allow attackers to escalate privileges to root on target machines. The vulnerabilities, disclosed in a report by Erica Windisch of Cyberdione Labs, affect how the service handles network connection forwarding and were patched just days after their public release.

What happened

The core issue lies in the Tailscale SSH server’s handling of Unix socket forwarding. When a user establishes an SSH session, the Tailscale background process performs the forwarding operation with root privileges. Although the system checks the path of the socket being accessed, a timing vulnerability allowed attackers to swap the path after the check but before the connection was established. This race condition effectively bypassed safeguards meant to restrict access to sensitive system sockets.

In laboratory tests, Windisch demonstrated that an attacker who already controlled a device permitted by the network policy could forward connections to the Docker control socket or the tailscaled local API. This access granted a root shell and the ability to read sensitive files like /etc/shadow without needing administrator credentials. The attack requires no stolen passwords or keys, only a foothold on a trusted device within the Tailscale network.

Tailscale clarified that these flaws do not allow unauthenticated attackers to connect to arbitrary servers. Access is still governed by the network’s policy file, meaning an attacker can only reach machines they are already authorized to access. However, once inside a permitted session, the privilege escalation allows lateral movement to root-only services. The company described the issues as serious security problems but rejected the characterization of the exploit as a self-replicating worm, noting it relies on existing policy permissions rather than autonomous spread.

How it works

The vulnerability exploits the difference between permission checking and execution context. Previously, the Tailscale process verified the socket path and then performed the forwarding operation as root. By swapping the socket path during this window, an attacker could trick the system into connecting to a privileged socket instead of the intended one. The fix in version 1.104.4 changes this behavior so that forwarding is carried out as the logged-in user rather than as root. It also shifts reliance from internal path checks to the operating system’s native file permissions, which are more robust against such race conditions.

This change specifically addresses bulletin TS-2026-014, which covers the socket-forwarding flaws. The update also resolves three other issues: a memory exhaustion bug that could crash the Tailscale process (TS-2026-015), a flaw in the tailscale serve feature allowing remote node control via Unix sockets (TS-2026-016), and a header leakage issue in TLS serve configurations (TS-2026-017). The Tailscale SSH server runs on Linux and the open-source macOS build, though the attacking device can be any platform.

Key details

• Affected versions: The oldest affected version is not specified, but version 1.104.4 contains the fixes.
• Prerequisites: Attackers must already control a device trusted by the network policy with SSH forwarding enabled.
• Impact: Successful exploitation grants access to root-only sockets, such as the Docker socket or tailscaled local API.
• Headscale users: The self-hosted headscale control server (version 0.29.5) does not yet fix these issues, and SSH forwarding cannot be disabled in its policy.
• Disclosure: The report was published without prior coordination; Tailscale received it two hours before public release.
• No CVEs: As of publication, the four security bulletins have no assigned CVE identifiers or severity scores.

Why it matters

For engineering teams using Tailscale for infrastructure access, this incident highlights the risks of implicit trust in device identity models. Because Tailscale SSH uses device identity rather than passwords, compromising a single trusted device can provide a pathway to critical systems if forwarding is enabled. The speed at which the exploit can move laterally—under a second per step in tests—means that detection and response times must be extremely fast to prevent widespread compromise.

The situation is particularly challenging for users of headscale, the open-source alternative to Tailscale’s control plane. Since headscale currently lacks the ability to disable SSH forwarding in policy and has not yet released a fix, administrators using this setup must treat every SSH grant as potentially granting root access. This underscores the importance of understanding the differences between managed services and self-hosted alternatives when evaluating security postures.

What you can do

• Update all Tailscale clients and servers to version 1.104.4 or later immediately.
• If updating is not possible, set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment to block forwarding.
• Review SSH access rules to ensure only necessary devices and users have permission to connect.
• Enable SSH check mode for sensitive systems to require re-authentication before sessions start.
• For headscale users, restrict SSH grants aggressively and monitor for unauthorized root-level activity.
• Reimage and delete compromised devices from the control plane if you suspect a breach, as reimaging alone does not revoke device keys.