Tailscale SSH report details potential root access from compromised nodes
Security researcher Erica Windisch of Cyberdione Labs has published a report describing how a compromised device could obtain root-level access on other reachable servers through Tailscale SSH. The lab testing covered Tailscale version 1.104.2 and headscale version 0.29.5, a self-hosted alternative control server. At publication, Tailscale had issued neither a security bulletin nor a CVE identifier, and no fixed version was available.
The reported attack requires an attacker to have already compromised a device and for the network's access rules to permit that device to connect to the intended target. Tailscale SSH rules authorize a device rather than relying on the connecting user's conventional password or SSH key, so the described path does not require the attacker to steal credentials for the target server.
Forwarding is central to the reported attack path
Windisch's Tailworm report says that SSH port forwarding can cause the root-level Tailscale process to connect to system sockets that should be restricted to root. In the lab, this allowed the researcher to obtain root access and read the system password file without administrator permissions. Other methods described replacing a root-owned socket and racing a safety check between a path validation and its subsequent use.
The report further describes capturing a key used to enrol devices and joining an attacker-controlled machine to the network as a trusted server. That final stage completed only where Tailnet Lock was not enabled. Windisch characterises the overall outcome as wormable: a single compromised device could spread to devices permitted by access rules, in testing, in less than a second for each step. These were laboratory results, not evidence of attacks against production networks.
Scope remains under review
Tailscale vice president of engineering Mike Shaver said publicly that the company had received the report, had been examining similar areas with external security specialists and had identified issues it was working to fix. He said Tailscale was still determining which configurations are affected and was not recommending that all customers disable Tailscale SSH.
The report is one of 11 findings involving Tailscale SSH, app connectors, the serve feature, the DERP relay and headscale. Its app connector finding concerns the experimental conn25 feature, which the report says could allow a permitted user to send traffic to destinations that security teams had not approved, including cloud metadata services. The specific claims have not been publicly reproduced by another researcher or confirmed by Tailscale.
Configuration changes available before a patch
For hosted Tailscale deployments, administrators can disable forwarding on individual SSH rules. Headscale 0.29.5 does not offer that control, and the report advises treating every SSH grant there as root access on the target. The report says narrowly written, single source-to-destination rules stopped spread in its tests, a principle also relevant to an exploit chain reached root on an Ubuntu host where an exploit chain reached root on an Ubuntu host.
Teams should review broad identity- or tag-based SSH grants, remove unnecessary app connector permissions and remove any tailscale serve forward directed to a Unix socket. Tailscale also recommends node-key expiry, automatic updates and SSH check mode. Check mode adds a login step but does not resolve the reported privilege escalation.
If a device is compromised, it should be deleted in the control plane rather than merely reimaged, because copied keys may remain valid. Until Tailscale clarifies affected configurations and releases fixes, the practical business implication is to reduce SSH reachability and forwarding privileges to the smallest explicitly required set.