Unpatched Tailscale SSH flaws could let one hacked device gain root on other servers

A security researcher has disclosed unpatched flaws in Tailscale SSH that could let an attacker who already controls one device on a tailnet gain root access on other servers the network's rules allow it to reach, The Hacker News reported on October 25. Erica Windisch of Cyberdione Labs published the findings in a report called "Tailworm" after three days of lab testing on Tailscale 1.104.2 and the open-source control server headscale 0.29.5. No CVE identifier, fixed version or security bulletin existed at the time of publication, which makes configuration hardening the only defense for now.

What happened

According to The Hacker News, the report contains 11 findings, covering app connectors, the serve feature, the DERP relay and headscale as well as SSH. The SSH issue requires two conditions: Tailscale SSH must allow port forwarding, and the attacker must already control a device that the access rules permit to connect to the target, for example through a vulnerable web app, a poisoned package, phishing or stolen credentials. Tailscale itself does not provide that foothold.

The publication noted that the report describes tests on software in a lab, not attacks on real networks. No other researcher has publicly reproduced the findings, Tailscale has not confirmed the specific technical claims and the proof-of-concept code is not public.

Technical details

The Hacker News said the report describes three methods. In the first, standard SSH port forwarding caused the root-level Tailscale process to connect to a root-only system socket, which in the lab gave root access. In the second, a root-owned socket was replaced with one controlled by the attacker. The third abused a time-of-check to time-of-use race condition to capture an enrollment key and join an attacker-controlled machine to the network as a trusted server; that chain only worked end to end on networks without Tailnet Lock.

Windisch calls the issue "wormable", meaning one compromised device could spread to every device the rules allow. Some researchers dispute the label, and the spread was measured only in the lab. Windisch also said an app connector finding involving the experimental conn25 feature "may be more impactful to some organizations", as it can let a permitted user reach unapproved destinations such as a cloud metadata service.

Who is affected

Mike Shaver, Tailscale's vice president of engineering, wrote on Reddit that the company received the report, had been examining the same areas with outside specialists and found issues it is working to fix, according to The Hacker News. He said Tailscale is still determining which setups are affected and is not recommending that everyone disable Tailscale SSH. On Tailscale's hosted service, port forwarding can be disabled per rule, while on headscale 0.29.5 it cannot. The disclosure itself is disputed: Windisch described it as "reported but not coordinated" and said she sent the report to Tailscale the Saturday before publication.

What to do

• Write SSH access rules as single source-to-destination pairs and remove broad identity- or tag-based grants.
• Disable SSH port forwarding where possible, and treat every headscale 0.29.5 SSH grant as root access on the target.
• Remove app connector permissions from devices that do not need them and drop any tailscale serve forward pointing to a Unix socket.
• Enable Tailnet Lock and node-key expiry, and delete compromised devices at the control plane, since reimaging alone does not revoke copied keys.