A lab report claims Tailscale SSH forwarding lets one hacked device gain root on reachable servers. No patch or CVE exists yet.
A security researcher has published lab findings claiming that Tailscale SSH, the remote-login feature built into the popular Tailscale networking tool, can be abused so that one compromised device gains root access on other servers it is allowed to reach. Root is the all-powerful administrator account on Linux and Unix systems. The report, called Tailworm, was released on October 25 by Erica Windisch of Cyberdione Labs. It describes 11 findings in total. At the time of reporting, Tailscale had issued no fix, no security bulletin and no CVE identifier, which is the standard tracking number for publicly known vulnerabilities. The company has said publicly that it is working on the problems.
Windisch spent three days testing Tailscale version 1.104.2 and headscale version 0.29.5 in a lab environment. Headscale is a self-hosted alternative to Tailscale's own coordination service. Some organisations run it so they can manage their network without relying on the company's hosted platform.
The report covers several parts of the Tailscale ecosystem: Tailscale SSH, app connectors, the "serve" feature, the DERP relay servers that pass traffic between devices when they cannot connect directly, and headscale itself. The headline finding is a privilege escalation in Tailscale SSH. Privilege escalation means an attacker with limited access gains higher-level control.
Windisch stresses that the work was carried out against test systems, not live networks. She says the proof-of-concept code was not released publicly and was shared only with Tailscale's security contact.
Mike Shaver, Tailscale's vice president of engineering, responded on Reddit. He said the company had received the report. He added that Tailscale had already been reviewing the same areas with outside security specialists and had identified issues it is now fixing. According to Shaver, the company is still determining which configurations are affected. He also said Tailscale is "not recommending that everyone disable Tailscale SSH."
The way the findings became public has also drawn criticism. Writing on Hacker News, Windisch described the disclosure as reported but not coordinated. At least one commenter there called it irresponsible to publish without first giving Tailscale the chance to respond.
According to the report, two conditions must both be true for the SSH attack to work:
The tested versions were Tailscale 1.104.2 and headscale 0.29.5. The sources do not state whether other versions are affected, and they do not name specific sectors or regions.
The type of deployment matters a great deal. On Tailscale's hosted service, administrators can turn off forwarding for each individual access rule. On headscale 0.29.5, the report says forwarding cannot be disabled at all. For that reason, Windisch advises headscale operators to assume that any SSH permission they grant effectively hands over root on the target machine.
A separate finding concerns an experimental feature called conn25, part of Tailscale's app connectors. Windisch told The Hacker News this issue may matter more to some organisations than the SSH flaw. She says it could let an authorised user send traffic to destinations the security team never approved. One example is a cloud provider's metadata service, an internal endpoint that can hand out server credentials.
Standard SSH servers decide who can log in by checking a password or a cryptographic key. Tailscale SSH works differently. It identifies the device that is connecting, and an access rule decides whether that device may open a session on the target. That makes administration simpler. The downside is that whoever controls a permitted device inherits that device's permissions, with no password or key to steal.
This means the attack does not start with Tailscale. An intruder first needs a foothold on one machine. The report lists familiar ways to get one: a vulnerable web application, a tampered software package, phishing, or stolen login details.
From there, the report describes abusing SSH port forwarding. Port forwarding is a normal feature that lets an SSH session tunnel network connections through to the remote machine. The Tailscale service on the target runs as root. Windisch says she could make it connect, on behalf of an ordinary session, to a local system socket that only root should be able to reach. A socket is a communication endpoint that programs use to talk to each other. In the lab this produced root-level access almost immediately, including reading the system's password file, without administrator rights.
The report describes two further techniques. One involved substituting an attacker-controlled socket for one owned by root, which allowed root commands to be run against certain services. The other defeated a safeguard meant to limit which files forwarding can touch. It did this by exploiting a timing gap between when the system checks a file path and when it actually uses that path. Security researchers call this a "race condition." In the lab, that chain went on to capture a device-enrolment key and use it to add an attacker's machine to the network as a trusted server.
That final step only worked fully on networks without Tailnet Lock, a Tailscale feature that requires trusted signatures before new devices can join. With Tailnet Lock enabled, the report says the needed secrets were captured but the last step did not succeed.
Windisch calls the result "wormable." A worm is malicious code that spreads from machine to machine on its own. In her lab, a single compromised device could move to every device the access rules allowed, taking under a second per hop and needing no passwords, keys or user interaction. She argues that the mesh design can turn one ordinary breach into privileged access across a whole fleet of machines.
Not everyone agrees with that framing. Some researchers who read the report have publicly questioned whether "wormable" is accurate. Others have said the root-access finding is serious regardless of that label.
Several important caveats apply:
The report identifies two defences that limited the attack. First, access rules written as narrow, single source-to-destination pairs stopped the spread by themselves. Second, device keys bound to hardware, such as a TPM chip or Apple's Secure Enclave, held it back.
For administrators:
For everyday users:
ITVedas analysis: The main lesson here applies to more than one product. Identity-by-device networks are convenient, but they make every enrolled machine a potential master key, so tightly scoped access rules matter more than ever. Until Tailscale ships fixes, administrators should assume that broad SSH grants mean broad root access and narrow them accordingly.
Want to understand the technology behind this story? ITVedas has beginner-friendly guides on every IT topic.
Explore IT Chapters →