Tailscale Patches SSH Flaws That Let a Hacked Device Become Root on Its Peers

Tailscale has shipped client version 1.104.4 to close a cluster of weaknesses in Tailscale SSH, the SSH server built into its mesh-VPN agent. On an unpatched Linux node, an attacker who already controls one device that the network policy trusts could abuse SSH forwarding to reach resources reserved for root on another machine, and in a lab setting that was enough to land a root shell.

What happened

Tailscale SSH does not authenticate with passwords or keys. It decides who may log in from the identity of the connecting device and the rules in the tailnet's policy file. That design is convenient, but it also means an intruder needs no stolen credentials at all. A foothold on any device the policy already allows to open an SSH session, with forwarding permitted in that rule, is the whole prerequisite.

The weak spot is socket forwarding. The tailscaled daemon runs as root, and when a permitted SSH session asked it to forward a connection to a Unix socket on the server, the daemon validated the requested path and then carried out the forward with its own root privileges. A race between the check and the use let the session substitute a different path after validation had passed, which defeated the safeguard that was supposed to restrict which sockets could be reached.

In testing, forwarding to the Docker control socket on a target node produced a root shell and read access to the system's shadow password file, all without any administrative rights on that machine. Tailscale's own advisory describes the impact more narrowly, as access to root-only sockets such as the Docker socket or the tailscaled local API, but either outcome amounts to full control of the node.

The company stresses that the flaws do not let an unauthenticated outsider connect to arbitrary Tailscale SSH servers. Reach is bounded by the policy: an attacker only gets to the machines the policy already lets the compromised device SSH into. The SSH server itself ships only in the Linux build and the open-source macOS build, although the attacking device can run any platform.

Version 1.104.4 changes the server to perform forwarding as the logged-in user rather than as root, and leans on ordinary operating-system file permissions instead of the earlier path check. The release addresses four Tailscale security bulletins:

• TS-2026-014: the SSH socket-forwarding weaknesses above, letting a permitted session reach root-only sockets.
• TS-2026-015: a way for a permitted SSH session to exhaust the server's memory and crash tailscaled, cutting all Tailscale connectivity on that node.
• TS-2026-016: a flaw in tailscale serve where a forward to a Unix socket could reach the tailscaled local API and take remote control of the node, plus a related socket-substitution issue.
• TS-2026-017: with TLS serve and two or more mounts configured, one request could receive the permission headers belonging to another mount.

As of publication the bulletins carry no CVE identifiers or severity scores, and none states the oldest affected version. Tailscale says it has reproduced the main privilege-escalation issues, calls them serious, and is still working out which configurations are affected.

Why it matters

The disclosure sparked a dispute over the word "wormable". The researcher who reported the issues demonstrated a chain in which a single compromised device spread to every peer the policy allowed, with no passwords, no stolen keys and no user interaction, each hop taking well under a second. Tailscale rejects that framing: nothing here is self-replicating malware, the company argues, only lateral movement confined to the connections the policy already permits. Both sides can be right at once. In many real tailnets the policy is permissive enough that "every device the policy allows" is simply every device.

Two points deserve extra attention:

• Patching does not evict an attacker who is already in. A stolen device key remains valid until the node is deleted from the control plane. Reimaging the box does not revoke it, and Tailscale's notices do not address this scenario.
• Self-hosted headscale is in a worse position. On headscale, SSH forwarding is granted on every accepted session and cannot be switched off in the policy, so every SSH grant there should be treated as granting root. The latest headscale release, 0.29.5 from October 13, does not fix the reported issues.

The disclosure itself was not coordinated with the vendor. Tailscale says it received the report on the morning of Saturday 24 October, roughly two hours before it was published, and that its engineers were already examining the same area of the code. Neither party is aware of exploitation in the wild, and the proof-of-concept code has been shared only with Tailscale's security team. A separate flaw in the same Unix-socket forwarding path was fixed in version 1.98.9 back in June, and the report also covered Tailscale's app connectors and its serve and funnel features. The app-connector finding sits in conn25, an experimental feature that has not shipped, so the connectors customers use today are unaffected. Of the five serve and funnel findings, Tailscale fixed three and considers the other two to be working as designed.

What to do

1. Update every Linux and open-source macOS node to 1.104.4 or later, starting with servers that expose the Docker socket or run other root-owned services.
2. If a node cannot be updated yet, set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service. This disables forwarding without turning off Tailscale SSH and blocks several of the more serious findings.
3. Tighten the SSH section of your policy file. Grant SSH only to the users and devices that genuinely need it, and prefer explicit device-to-device pairs over broad group rules. Pairwise rules were one of the two controls that stopped the lateral-movement chain in testing.
4. Bind device keys to hardware such as a TPM where your platform supports it, so a stolen identity cannot be replayed from elsewhere. This was the other control that held.
5. Do not rely on SSH check mode as a fix. Re-authentication guards the start of a session; the forwarding abuse happens inside a session that has already been approved. Check mode is still worth enabling for sensitive hosts.
6. If you suspect a node was compromised, delete it from the control plane and re-enrol it. Patching or reimaging alone leaves its key usable.
7. Headscale operators should assume that every SSH grant equals root until a fixed release lands, and reduce those grants accordingly.

Weaknesses like these rarely show up in a port scan: the exposure lives in the access policy and in what one trusted machine can reach from another. An internal penetration test that starts from a single assumed-compromised node and maps how far it can travel is the most reliable way to find out whether your tailnet would contain the blast radius or hand over the keys. That kind of lateral-movement exercise is part of the penetration testing work our team carries out.