Summary
A single hacked device on a Tailscale network can be used to gain root access to other servers it can reach, according to a security researcher who pu…
The attack requires two things: Tailscale SSH set up to allow port forwarding, and an attacker who already controls one device that the network's access rules permit to connect to the target.
The findings were published on October 25 in a report called Tailworm by Erica Windisch of Cyberdione Labs. Windisch tested Tailscale version 1.104.2 and headscale version 0.29.5, the self-hosted server some networks use to run Tailscale instead of the company's hosted service, over three days in a lab.
The report describes tests on that software, not attacks against real networks. As of publication, Tailscale had issued no security bulletin, no CVE identifier, and no fixed version.
Tailscale has responded in public. Mike Shaver, the company's vice president of engineering, wrote on Reddit that Tailscale had received the report, had already been looking at the same areas with outside security specialists, and had found issues it is working to fix. Shaver said the company is still working out which setups are affected, and that it is "not recommending that everyone disable Tailscale SSH."
Tailscale SSH does not work like a normal SSH server. Rather than checking a connecting user's password or key, it identifies the device, and a single access rule decides whether that device may open an SSH session to a target.
Because of this, the attack needs no stolen passwords or keys. It needs a foothold on one device first, which the report says an attacker can get the usual ways: a vulnerable web application, a poisoned software package, phishing, or stolen login details. Tailscale does not create that first foothold.
How much an administrator can do about it depends on where the network is run. On Tailscale's hosted service, forwarding can be switched off per rule. On headscale version 0.29.5, forwarding cannot be turned off at all. The report says every SSH grant there should therefore be treated as giving root on the target.
In the lab, Windisch showed the problem in stages. Using standard SSH port forwarding, an ordinary session caused the root-level Tailscale process to connect to a system socket that only root should access, and the test gained root and read the system password file almost immediately, without administrator rights.
A second method replaced a root-owned socket with the attacker's, allowing direct root command execution against certain services.
A third method defeated a safety check meant to limit which files forwarding can access by racing the system between when it checks a file path and when it uses it. That chain went further in the lab, the report says: it captured a key used to enroll new devices and used the key to join an attacker's own machine to the network as a trusted server.
That last step worked from start to finish only on networks where Tailscale's Tailnet Lock feature was not enabled. On networks that do, the needed secrets were captured in transit, but the final step was not completed.
Windisch describes the overall result as "wormable." In the lab, one compromised device could spread to every device that the access rules allow, with no passwords, no stolen keys, and no user action, in under a second per step.
In the report's words, "the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed." That spread was measured in a lab, not seen on real networks.
The report names two things that held it back: access rules written as single source-to-destination pairs, which stopped the spread on their own, and device keys tied to hardware such as a TPM or Secure Enclave.
Some researchers who read the report have publicly questioned the "wormable" description, while others have called the root-access finding serious.
The SSH problem is one of 11 findings in the report, which also covers Tailscale's app connectors, its serve feature, the DERP relay used between devices, and headscale. Windisch told The Hacker News that the SSH privilege escalation "is worrying," but that the app connector finding "may be more impactful to some organizations." The app connector finding, in an experimental feature called conn25, lets a permitted user send traffic to destinations the security team never approved, including a cloud provider's metadata service, which can hand out server credentials.
All of the findings rest on Windisch's report alone. No other researcher has publicly reproduced them, and Tailscale has not confirmed the specific technical claims. Windisch said the proof-of-concept code behind the findings is not public, and that she provided it only to Tailscale's security contact.
Windisch has described the disclosure as "reported but not coordinated," writing as much on Ycombinator HN, and at least one commenter there called publishing without first reporting to Tailscale irresponsible.
In response to questions from The Hacker News, Windisch said she had in fact given Tailscale a copy of the report and the proof-of-concept code before the public post, sending them to the company's security contact on the Saturday beforehand. She said she had also raised concerns about Tailscale's architecture with the company's chief executive earlier, and had publicly posted a file hash and advised users to disable Tailscale SSH.
The report is the latest in a run of problems in the same part of Tailscale. Earlier in 2026, the company fixed several Tailscale SSH and server socket-handling flaws, including one where SSH Unix socket forwarding could reach a privileged socket, in version 1.98.9.
What to Do Now
Because there is no patch, the available steps are changes to how Tailscale SSH and related features are set up. The report and Tailscale's own advice overlap on most of them.
Tailscale also suggests enabling SSH check mode, which adds a login step before a session starts, and enabling automatic updates. Check mode does not fix the privilege escalation. It only adds another barrier in front of it.
Source: The Hacker News
