Unpatched Tailscale SSH Flaws Can Turn One Hacked Device Into Root on Other Servers, and There Is No Fix Yet

A researcher has published 11 findings against Tailscale, the mesh VPN many companies use to reach their servers, and the worst of them has no fix yet. In a lab, an attacker who already controlled one device used Tailscale SSH to get root on other servers that device was allowed to reach. No passwords, no stolen keys.

There is no patch, no CVE and no security bulletin. And the way the report went public has become its own fight.

How one foothold becomes root

The report, called "Tailworm," comes from Erica Windisch of Cyberdione Labs and was published on October 25. She tested Tailscale 1.104.2 and headscale 0.29.5, the self hosted control server, over three days in a lab. These are lab results, not attacks seen on real networks, as The Hacker News notes.

The attack needs two things: Tailscale SSH configured to allow port forwarding, and a device the attacker already owns that the access rules let connect to the target. That foothold comes the usual ways, from a vulnerable web app, a poisoned package, phishing or stolen logins. Tailscale does not create it.

What Tailscale changes is what happens next. Tailscale SSH identifies the connecting device instead of checking a password or key, and one access rule decides whether that device may open a session. SSH access is already a favorite target, which is why attackers bother hijacking Tor exit relays to harvest SSH passwords. Here no credentials are needed at all.

In the lab, standard SSH port forwarding made the root level Tailscale process connect to a socket only root should reach. That gave root and the system password file almost immediately. A second method swapped a root owned socket for the attacker's own to run root commands against some services. A third raced a check then use safety test on file paths, captured a key used to enroll new devices, and joined an attacker machine to the network as a trusted server. That last chain only worked with Tailnet Lock off; with it on, secrets were captured but the final step failed.

"Wormable," or not

Windisch calls the result wormable. In her lab one compromised device spread to every device the rules allowed, at under a second per step. In her words, "the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed." Some researchers questioned that label. Others called the root finding serious.

The other findings cover app connectors, the serve feature, the DERP relay and headscale. Windisch said an experimental app connector feature, conn25, lets a permitted user send traffic to destinations security teams never approved, including a cloud metadata service that can hand out server credentials, and that it "may be more impactful to some organizations."

Reported, but not coordinated

Windisch described the release as "reported but not coordinated." She said she sent the report and proof of concept to Tailscale's security contact the Saturday before posting, had raised architecture concerns with the CEO earlier, published a file hash, and advised users to disable Tailscale SSH. At least one Hacker News commenter called publishing without prior reporting irresponsible. The exploit code is not public, nobody else has reproduced the findings, and Tailscale has not confirmed the specific claims.

Mike Shaver, Tailscale's VP of engineering, wrote on Reddit that the company had already been examining the same areas with outside specialists, found issues it is fixing, is still working out which setups are affected, and is "not recommending that everyone disable Tailscale SSH." Earlier this year Tailscale fixed several SSH and socket flaws in version 1.98.9, including one where Unix socket forwarding could reach a privileged socket.

Until a fix ships, what held the attack back in the lab was access rules written as single source to destination pairs and device keys bound to hardware such as a TPM or Secure Enclave. On the hosted service, forwarding can be switched off per rule. On headscale 0.29.5 it cannot be switched off at all, so the report says every SSH grant there should be treated as root on the target.

Removing unneeded app connector permissions and serve forwards that point at Unix sockets, turning on node key expiry, and deleting a compromised device at the control plane all narrow the path, since reimaging a machine does not revoke keys already copied off it. Tailscale also suggests SSH check mode and automatic updates, though check mode adds a login step without fixing the escalation.

Some offers on this page may be paid placements or contain affiliate links.