Unpatched Tailscale SSH flaws can turn one hacked device into root on other servers, a researcher says
The Tailworm report says Tailscale SSH forwarding lets one compromised device gain root on servers it can reach. No patch yet; here's what to change.
The skim
- A researcher has published 11 findings against Tailscale and the self-hosted headscale server. The headline one: with Tailscale SSH and port forwarding allowed, one hacked device can get root on other servers it's allowed to reach.
- There's no patch, CVE or security bulletin yet. Tailscale says it got the report and is fixing issues, but isn't telling everyone to turn off Tailscale SSH.
- If you use Tailscale SSH, tighten your access rules and turn off SSH forwarding where you can. On headscale 0.29.5, treat every SSH grant as root access.
What happened
Erica Windisch of Cyberdione Labs published a report called Tailworm this weekend. It covers Tailscale client version 1.104.2 and headscale 0.29.5, tested in a lab from Oct. 22 to Oct. 24. The main problem is in Tailscale SSH, the built-in SSH server that runs as root and decides who gets in based on the device and your access rules, not a password or key.
According to the report, ordinary SSH port forwarding of Unix sockets lets a normal user make the root-level Tailscale process connect to, replace or delete privileged sockets. In the lab, that led to root command execution on target servers. One chain went further, grabbing a key used to enroll new devices and adding an attacker's machine to the network as a trusted server. That last step worked end to end only on networks without Tailscale's Tailnet Lock feature, The Hacker News reports.
Windisch calls it "wormable": in the lab, a compromised device could hop to every machine the rules allowed, "under a second per hop." The attacker still needs a first foothold, such as a hacked web app or a poisoned package. Other findings include an experimental app connector feature that can route traffic to unapproved destinations, such as cloud metadata services that hand out credentials.
Tailscale's response
Tailscale's VP of engineering, Mike Shaver, wrote on Reddit that the company had received the report, had already been reviewing the same areas with outside security specialists, and had found issues it is working to fix, according to The Hacker News. He said Tailscale is still working out which setups are affected and is "not recommending that everyone disable Tailscale SSH." As of Sunday, Tailscale's security bulletins page listed nothing new. No one else has publicly reproduced the findings, and Windisch says she has shared her proof-of-concept code only with Tailscale.
Why it matters
Many teams use Tailscale SSH to skip managing SSH keys. That convenience is the point of the criticism: if one device is compromised, broad access rules can turn it into a skeleton key. It's not the first issue in this area. In bulletin TS-2026-004, Tailscale fixed a Unix socket forwarding bug in version 1.98.9 that let an unprivileged user reach a privileged socket. And with flaws like PHP2Shell handing attackers footholds on web servers, what happens after the first break-in matters.
What to do now
- Write SSH access rules as single device-to-target pairs, not broad rules by identity or tag. The report says this was the one control that stopped the spread.
- Turn off SSH forwarding per rule on Tailscale's hosted service. On headscale 0.29.5 you can't, so treat every SSH grant as root.
- Drop unneeded app connector permissions, turn on node-key expiry, and delete any compromised device in the admin console. Reimaging won't revoke stolen keys.
Watch for a Tailscale bulletin and a fixed release in the coming days.
Sources: Tailworm report (Cyberdione Labs), The Hacker News, Hacker News discussion and Tailscale security bulletins.