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 published the findings this week.

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. When the report was published, Tailscale had issued no security bulletin, no CVE identifier, and no fixed version. The company has since said a patched client is close, as detailed in the update below.

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, and no other researcher has publicly reproduced them. Tailscale has since said its own investigation found privilege-escalation issues in Tailscale SSH that it considers serious, though it has not confirmed each of the report's specific technical claims and is still verifying which configurations are affected. 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.

  • Review your Tailscale SSH access rules. Write them as single source-to-destination pairs that name one device and one target, and remove broad rules that grant access by identity or tag. The report calls per-pair rules the one control that stopped the spread in testing.
  • Turn off SSH port forwarding where you can. On Tailscale's hosted service this is a per-rule setting. Tailscale has also published a daemon-level switch that works regardless of the control plane: set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service, which the company says turns off SSH forwarding without disabling Tailscale SSH and mitigates several of the more serious findings. This matters most on headscale version 0.29.5, where forwarding cannot be switched off per rule.
  • Remove app connector permissions from devices that do not need them.
  • Remove any tailscale serve forward that points at a Unix socket.
  • Turn on node-key expiry, so a stolen device key does not stay valid forever.
  • If a device is compromised, delete it at the control plane. Reimaging the machine does not revoke keys an attacker may have already copied off it.

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.

Update: Tailscale Confirms Privilege-Escalation Issues, Patch Expected Within a Day

On October 27, Tailscale published an investigation and remediation update on the Tailscale SSH findings. The company said most of the issues it had identified concern privilege escalation, and that in some cases a user already authorized to connect over Tailscale SSH "may be able to perform actions beyond the permissions of their configured local user, including potentially gaining elevated privileges." It called them "serious security issues."

Tailscale said its engineers had built fixes for most of the identified issues and were finishing testing, and that it was "targeting a release within the next 24 hours," subject to that testing. It has not yet published fixed version numbers or a CVE. The company said it would release a security advisory with the confirmed vulnerabilities, affected versions, and configurations once the patch ships, followed by a technical write-up.

Tailscale repeated that it is "not recommending that everyone disable Tailscale SSH," and that whether a setup is exploitable depends on the permissions a user or device holds and how the system is configured, which it is still verifying.

(The story was updated after publication on October 27, 2026, to include Tailscale's investigation and remediation update.)

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.