Tailscale rushes patches after uncoordinated disclosure of Tailworm SSH flaws

Tailscale said on Monday it received a report from Cyberdione Labs describing 11 vulnerabilities in its client and in the self-hosted headscale control server, and that it expected to issue a fix by October 27. The researchers, who published details over the weekend under the name Tailworm, ran the tests on the released versions, Tailscale 1.104.2 and headscale 0.29.5, from October 22 through October 24.

The most serious findings involve Tailscale SSH, which grants access by device identity and network policy instead of passwords or keys. The report rates six flaws high severity, four of which affect Tailscale SSH. The Tailworm write-up says that Tailscale SSH carries out certain forwarding tasks as root and that the checks designed to limit them can be evaded. A regular SSH session in the lab obtained root and read /etc/shadow within seconds. The most critical issue can allow root execution, capture of enrollment keys, and deletion of root-owned files, according to a table in BleepingComputer's coverage.

Exploitation requires one approved device plus one SSH policy rule that allows forwarding; on headscale forwarding is granted automatically, while on Tailscale's SaaS it is per rule. In the lab, one infected machine gained root on other hosts and added a rogue device that appeared legitimate, then spread from system to system in under a second per hop without human action. The first foothold could come from phishing, a vulnerable web application, or a malicious software package.

Other findings affect the experimental app connector feature, the serve feature, headscale, and the DERP relay client. Cyberdione Labs found that a device granted the connector capability can steer traffic to any chosen target, including cloud metadata endpoints and internal networks, bypassing access policies; in Kubernetes, this could expose cluster services. The headscale flaw allows unauthenticated memory exhaustion that can crash the control server and block new device onboarding, while a malicious relay can cause client-agent memory exhaustion, and a serve forward to a Unix socket can expose a node's administrative interface.

Mike Shaver, VP of engineering at Tailscale, said the vendor had already started its own review when the report arrived. The vendor said on Monday that most of the issues already had fixes in place. He described the issues as serious but not the same as an unauthenticated attacker connecting to arbitrary machines, because the impact depends on how SSH access is configured. Tailscale does not recommend that everyone disable Tailscale SSH; instead it advises reviewing SSH access policies, setting TS_SSH_DISABLE_FORWARDING=1 to disable forwarding without disabling SSH, and temporarily tightening access to sensitive systems. As of Tuesday, fixes for several findings had landed in Tailscale's public code repositories but not yet in a numbered release.

Neither Tailscale nor the Tailworm report mentions exploitation in the wild.

Defenders should review their rules today. Swap out permissive identity- or tag-level SSH policies for per-pair rules that specify a single source and destination, and disable forwarding in any rule that offers that option. Because headscale 0.29.5 does not allow disabling forwarding, treat every SSH permission on that version as equivalent to root access. Disable Tailscale SSH on hosts that don't require it by running tailscale set --ssh=false after ensuring an alternate access path, revoke unused app connector privileges, delete serve forwards that target Unix sockets, and enable node-key expiry. For any compromised device, remove it from the control plane, since wiping the OS does not invalidate keys that attackers may have exfiltrated.