October 25 Tailworm report shows one device reaching root

Erica Windisch of Cyberdione Labs published a report on October 25 showing that a single hacked device on a Tailscale network can be used to reach root on other servers it is allowed to connect to. There is no CVE, no security bulletin, and no fixed version. The report, called Tailworm, describes tests against Tailscale 1.104.2 and headscale 0.29.5, run over three days in a lab against the software itself rather than any real network.

The attack needs two things. Tailscale SSH has to be configured to allow port forwarding, and the attacker has to already control one device that the network’s access rules permit to connect to the target. Tailscale does not hand an attacker that first device. The report lists the usual ways in: a vulnerable web app, a poisoned package, phishing, stolen credentials.

What makes the foothold worth so much is how Tailscale SSH authenticates. It does not check 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. Once an attacker owns a permitted device, no stolen secrets are needed to use the SSH grants that device already holds.

Windisch demonstrated the privilege escalation in stages. In the first, an ordinary SSH session using standard port forwarding caused the root-level Tailscale process to connect to a system socket that only root should touch; the test read the system password file almost immediately, with no administrator rights. A second method swapped a root-owned socket for the attacker’s, giving direct root command execution against certain services. A third defeated a safety check meant to limit which files forwarding can reach, by racing the gap between when the system checks a file path and when it uses it. That chain went furthest in the lab: it captured a key used to enroll new devices and used it to join the attacker’s own machine to the network as a trusted server.

The enrollment step completed only where Tailnet Lock was off. On networks running Tailnet Lock, the report says the secrets were still captured in transit, but the final join did not go through.

Windisch calls the overall result “wormable”: in the lab, one compromised device could spread to every device 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. Some researchers who read the report have questioned the wormable framing; others have called the root-access finding serious.

Two things slowed the spread in testing. Access rules written as single source-to-destination pairs stopped it on their own, and device keys bound to hardware such as a TPM or Secure Enclave resisted theft.

The SSH bug is one of 11 findings. Windisch told The Hacker News the SSH privilege escalation “is worrying,” but that an app connector finding “may be more impactful to some organizations.” In an experimental feature called conn25, a permitted user can send traffic to destinations the security team never approved, including a cloud provider’s metadata service, which can hand out server credentials.

Tailscale has responded in public. Mike Shaver, the company’s VP of engineering, wrote on Reddit that Tailscale had received the report, had already been looking at the same areas with outside specialists, and had found issues it is working to fix. He said the company is still working out which setups are affected and is “not recommending that everyone disable Tailscale SSH.”

The disclosure itself is contested. Windisch described it as “reported but not coordinated” on Hacker News, and at least one commenter there called publishing without first reporting to Tailscale irresponsible. Asked about it, Windisch said she had in fact sent Tailscale the report and the proof-of-concept code on the Saturday before the public post, that she had raised architectural concerns with the CEO earlier, and that she had posted a file hash and told users to disable Tailscale SSH. The proof-of-concept code is not public; she says she gave it only to Tailscale’s security contact. No other researcher has publicly reproduced any of the findings, and Tailscale has not confirmed the specific technical claims.

This is the latest in a run of problems in the same part of the product. Earlier in 2026, Tailscale fixed several 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

There is no patch, so every available step is a configuration change. The report and Tailscale’s own advice mostly agree.

• Rewrite your Tailscale SSH access rules as single source-to-destination pairs, each naming one device and one target, and drop 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 the hosted service it is a per-rule setting. On headscale 0.29.5 it cannot be turned off at all, so treat every SSH grant there as root on the target.
• 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 does not revoke keys an attacker may already have copied off it.

Tailscale also suggests SSH check mode, which adds a login step before a session starts, and automatic updates. Check mode does not fix the privilege escalation; it adds a barrier in front of it.