“Tailworm”: Tailscale SSH Flaws Allow Escalation to Root

On October 24, 2026, researcher Erica Windisch (Cyberdione Labs) published “Tailworm”, a security assessment of Tailscale and headscale listing eleven findings. Its core concerns Tailscale SSH: any user allowed to log in, even with an ordinary account, could gain root on the target server by abusing Unix socket forwarding. Chained together, the bugs enabled automated machine-to-machine spread in a lab, at under a second per hop. Because the report went public about two hours after it reached the vendor, Tailscale had to ship fixes under pressure; they are available from version 1.104.4.

What happened

Tailscale is a WireGuard-based mesh VPN widely used for remote access to servers and administration environments. Its Tailscale SSH feature replaces classic SSH authentication with device identity and the access rules defined in the tailnet policy file. headscale is an open-source, self-hostable implementation of the control server.

According to Tailscale’s timeline, concerns about Tailscale SSH circulated on social media on Friday, October 23, and the company started investigating. It received the report on the morning of Saturday, October 24; the researcher published it roughly two hours later, before any fix existed. The uncoordinated disclosure drew criticism, while the researcher argued that rapid awareness would speed up remediation.

Tailscale engineers worked on fixes over the weekend. On October 26, the company published an investigation update and its security bulletins. Version 1.104.4 was tagged on October 27, and a full write-up followed on October 28. The researcher, for her part, credits Tailscale with a “rapid and substantive response.”

Technical analysis

Root escalation through socket forwarding

Findings 1 to 3 make up the most serious scenario. Unix socket forwarding requested by an SSH client was performed by the tailscaled process, which runs as root. The path allowlist (home directory, /tmp, /run/user) was checked purely lexically, so a rename-based TOCTOU race could defeat it.

According to the report, an ordinary SSH user could therefore:

• execute code as root by reaching the root-owned Docker socket;
• replace Tailscale’s control socket and capture an enrollment authkey;
• delete or chmod arbitrary root-owned files;
• dial systemd’s private bus as root and turn that into a root shell.

The researcher points out that OpenSSH drops privileges before handling forwarding, and that Dropbear fixed the same bug class (CVE-2025-14282) in version 2025.89. Tailscale summarizes the issue as an authenticated session being able to perform operations beyond the privileges of its configured local user, including through SSH forwarding.

The “worm”: spread bounded by access policy

The report describes a full chain: hold the socket bind, intercept local API traffic, capture an authkey, then enroll a rogue node under the victim’s identity. It was demonstrated end to end on a tailnet with Tailnet Lock disabled. In the lab, automated spread to every server reachable under the policy took less than a second per hop, with no user credentials and no interaction.

Tailscale disputes the “self-replicating worm” label, describing it as lateral movement limited to connections the policy allows. Both readings agree on the key point: the blast radius depends directly on how broad your SSH rules are. The researcher notes that per-pair grants stopped the spread, and that hardware-bound device credentials (TPM, Secure Enclave) prevented identity theft.

The other findings

Who is affected?

The organizations most exposed are those using Tailscale SSH with rules that allow local or remote forwarding, especially when those rules are broad (access granted to an entire identity or tag, privileged target accounts). Deployments running regular OpenSSH over Tailscale are not affected by the SSH chain. Self-hosted environments on headscale 0.29.5 deserve special attention: according to the report, forwarding cannot be disabled through policy there.

Why it matters

Zero-trust access tools concentrate authorization on device identity. That is a strength, but also a single point of failure: a laptop compromised through phishing, a vulnerable web application or a malicious software package is enough to inherit every permission that device holds. If those permissions include SSH access to many servers, a local privilege escalation becomes a fleet-wide compromise.

The episode is also a reminder that a network access tool is a critical part of the administration chain. It must be inventoried, patched and monitored just like a VPN or a bastion host.

MITRE ATT&CK mapping

Neither the vendor nor the researcher provides an ATT&CK mapping. The table below is an indicative Defensy reading based on the lab scenario described.

Recommendations

1. ImmediateUpgrade to Tailscale 1.104.4 or later

   Start with servers exposing Tailscale SSH, then cover every node. Check the version actually deployed on each device, including containers and pinned images.

2. ImmediateDisable SSH forwarding where it is not needed

   In the policy file, turn off local and remote forwarding for rules that do not require it. On nodes not yet upgraded, bulletin TS-2026-014 advises setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service.

3. ImmediateTreat every SSH grant as root on headscale

   On headscale 0.29.5, sharply restrict SSH rules, or temporarily fall back to regular OpenSSH over the tunnel until a fix is available.

4. Short termTighten your SSH access policy

   Replace identity-wide or tag-wide rules with per-pair source/destination grants, avoid privileged target accounts and consider check mode for sensitive systems, keeping in mind that it only gates session establishment, not forwarding.

5. Short termHarden node identity

   Enable Tailnet Lock, node key expiry on servers and, where possible, hardware-bound state. Rotate any authkeys reachable from potentially exposed hosts.

6. Medium termMonitor from outside the host

   Forward control-plane logs (node enrollment, policy changes) and server telemetry (socket creation, docker.sock access, unexpected shells) to your SIEM. If a host is compromised, delete the device at the control plane: reimaging does not revoke copied keys.