Teams that use Tailscale to provide SSH access to their servers have homework this week: the Tailworm report, published on October 25, 2026 by Erica Windisch of Cyberdione Labs, describes 11 flaws in Tailscale and headscale that, in a lab setting, allowed an attacker to jump from a compromised device to root on other nodes on the network without stolen passwords or keys. Tailscale has acknowledged that it’s fixing issues in those areas, but there’s still no advisory, CVE, or patched version.
Tailworm for teams using Tailscale SSH: the key facts in 20 seconds
- Tailworm documents 11 flaws tested against Tailscale 1.104.2 and headscale 0.29.5.
- The main risk is socket forwarding in Tailscale SSH, handled by a process that runs as root.
- There’s no patch or CVE yet; Tailscale advises against disabling SSH across the board.
- Peer-to-peer rules and hardware-bound keys stopped the attack.
Tailscale has spread as an alternative to classic VPNs and SSH bastions because it connects machines over WireGuard with centralized access policies, and many teams also use it to log into production servers via Tailscale SSH. That convenience is exactly what the report examines. The findings come from one researcher’s lab tests and haven’t yet been independently reproduced, so they’re worth treating as serious warnings rather than confirmed incidents.
Where the problem lies
The core of the report is architectural. Tailscale’s SSH server lives inside tailscaled, the client daemon, which runs with root privileges. When a rule allows forwarding ports or Unix sockets, that privileged process is the one that opens or replaces the sockets — including ones only root should touch, like Docker’s. In testing, a user with a normal SSH session reached root and read /etc/shadow, and another variant of the flaw executed code as root through a local daemon.
The rest of the findings extend the scope to other features: experimental app connectors, which according to the report leaked traffic out toward cloud or Kubernetes metadata services; tailscale serve and Funnel when pointed at Unix sockets; the DERP relay client; and the headscale server, which also gets a resource-exhaustion warning. None of these is exploitable straight from the internet — the attacker needs to already control a device on the network, something that can arrive through a vulnerable app, a poisoned dependency, or an infected laptop.
What worries administrators is the speed of propagation described. Every node knows the full list of its peers, so from the first compromised device the attacker can see every possible target, and the lab chain advanced in under a second per hop. With Tailnet Lock enabled, the final step — enrolling a fake server on the network — failed, according to The Hacker News.
Tailscale’s response and the disclosure debate
Windisch says she sent the report and proof of concept to Tailscale’s security contact the Saturday before publishing it, without waiting for a coordinated process, and that decision has drawn criticism on forums like Hacker News. Some researchers also dispute whether the attack qualifies as a worm, though they agree the escalation to root is serious.
Mike Shaver, Tailscale’s vice president of engineering, responded on Reddit that the company was already reviewing those areas with outside specialists and is working on fixes, though it’s still determining which configurations are exposed. His recommendation is to review SSH policies, limit who can forward ports, enable check mode, and keep automatic updates on — not to disable Tailscale SSH everywhere. OpenSecurity breaks down the 11 flaws and Tailscale’s earlier advisories in Tailworm: 11 unpatched Tailscale flaws could grant root on other servers.
Checklist for systems teams
Until a patch lands, the report suggests measures any team can review in an afternoon:
- Audit the policy’s SSH rules and replace broad group- or tag-based grants with source-to-destination allowances.
- Deny port forwarding on every rule. Headscale 0.29.5 doesn’t have that option yet, so every SSH grant should be treated as root access.
- Disable Tailscale SSH on machines that don’t need it with
tailscale set --ssh=false, but only after confirming there’s another way in. - Remove unused app connector permissions and
serveforwards pointed at Unix sockets. - Turn on node key expiry, and if a device is compromised, remove it from the control plane — reinstalling it doesn’t invalidate keys that have already been copied elsewhere.
The case is a reminder that a zero-trust network depends as much on its policies as on its software. The protection that worked best in the lab wasn’t a patch, but a tight access rule. For anyone who’d rather run their own private network without third-party services, we explained how to turn any Linux box into your own VPN with WireGuard, though that route means managing by hand what Tailscale automates.
Frequently Asked Questions
Have the Tailworm flaws been patched?
No. As of October 26, 2026, Tailscale had not published an advisory, a CVE, or a fixed version, though it says it’s working on fixes.
Does Tailworm affect headscale?
Yes. The report tested headscale 0.29.5, where port forwarding also can’t be disabled in SSH rules.
Can it be exploited from the internet?
Not directly. The SSH attack chain requires the attacker to already control a device on the Tailscale network.
What should be reviewed first?
The policy’s SSH rules: replace broad grants with source-to-destination pairs and deny port forwarding.
Sources:
- OpenSecurity: Tailworm, 11 unpatched Tailscale flaws
- Cyber Security News: Tailscale SSH flaws could let hackers gain root access across servers
- The Hacker News: Unpatched Tailscale SSH flaws could let a hacked device reach root on other servers
- Tailworm: Cyberdione Labs report
- Tailscale: Tailscale SSH documentation
