Security researcher Erica Windisch of Cyberdione Labs has reported Tailscale SSH weaknesses that, in laboratory tests, allowed an attacker controlling one device to gain root access on other reachable servers. The attack required SSH port forwarding to be allowed and network access rules permitting the compromised device to connect to its targets.
Windisch published the findings on October 25 in a report titled Tailworm, following three days of testing with Tailscale 1.104.2 and headscale 0.29.5, a self-hosted alternative to Tailscale’s hosted control service. The findings describe laboratory attacks, with no reported exploitation against real networks.
According to The Hacker News, Tailscale had published no security bulletin, CVE identifier or fixed release for these findings at the time of publication. No other researcher had publicly reproduced them, and Tailscale had not confirmed the specific technical claims.
Tailscale vice president of engineering Mike Shaver said on Reddit that the company had received the report, had already been investigating the same areas with outside security specialists, and had identified issues it was working to fix. He said the company was still determining which configurations were affected and was “not recommending that everyone disable Tailscale SSH.”
How the reported SSH attacks worked
Tailscale SSH uses device identity and access rules to authorize connections, rather than requiring a conventional SSH password or key. The reported attacks therefore did not require stolen SSH credentials, but they did require an existing foothold on an authorized device. The findings do not establish a way to obtain that initial access.
In one test, Windisch reported that ordinary SSH port forwarding caused the root-level Tailscale process to connect to a system socket restricted to root. That provided root access and allowed the test to read the system password file without the connecting user having administrator privileges.
A second method reportedly substituted an attacker-controlled socket for a root-owned socket, enabling root command execution through certain services. A third exploited a race between a file-path safety check and the subsequent use of that path, bypassing restrictions on which files forwarding could access.
The third chain also captured a key used to enroll devices and used it to add an attacker-controlled machine to the network as a trusted server. That sequence completed only where Tailnet Lock was disabled. With Tailnet Lock enabled, the report says the necessary secrets were captured in transit, but the final enrollment step was not completed.
Windisch described the overall result as “wormable,” reporting that compromise could spread through devices permitted by access rules in under a second per step, without passwords, stolen keys or user interaction. That speed and propagation were demonstrated in the lab. Some researchers publicly questioned the wormable characterization, while others described the root-access finding as serious.
Configuration determines exposure
The report identified access rules specifying individual source-to-destination device pairs as a control that stopped propagation in testing. Hardware-bound device keys, such as those tied to a TPM or Secure Enclave, also constrained the attacks.
Forwarding controls differ by deployment. On Tailscale’s hosted service, SSH port forwarding can be disabled per rule. According to the report, headscale 0.29.5 cannot disable it; Windisch therefore argued that SSH grants on that version should be treated as granting root access to their targets.
The SSH attacks are part of 11 findings covering Tailscale features and headscale. Windisch also reported that the experimental app connector feature conn25 could let a permitted user reach destinations administrators had not approved, including a cloud metadata service capable of providing server credentials. This remains a researcher claim, rather than evidence of credentials stolen from a production environment.
The reported configuration measures include narrowing SSH permissions, disabling forwarding where supported, removing unnecessary app connector permissions and removing tailscale serve forwards to Unix sockets. Enabling node-key expiry limits stolen-key validity; deleting a compromised device at the control plane revokes access that reimaging alone may leave intact.
Tailscale also recommends SSH check mode, which adds a login step before a session, and automatic updates. Check mode adds an access barrier but does not fix the reported privilege escalation.
Windisch said the proof-of-concept code was shared only with Tailscale’s security contact. Although she characterized the disclosure as “reported but not coordinated,” she told The Hacker News that she had sent the company both the report and the code before publication.
