Tailscale has released version 1.104.4 to fix flaws in its built-in SSH server that could let an attacker reach services and files on other servers that only the root user should be able to touch.
The flaws are in how Tailscale SSH forwards network connections, a job the Tailscale background process carries out with root privileges. To use them, an attacker must already control a device that the network’s access rules permit to open an SSH session to the target, with forwarding allowed in that rule.
The flaws come from a report called Tailworm, published days before the fix by Erica Windisch of Cyberdione Labs, who tested released versions of the Tailscale client and the self-hosted headscale control server in a lab.
Tailscale SSH decides who can connect using a device’s identity and the network’s policy file, not a password or key, so an attacker does not need stolen credentials, only a foothold on a device the policy already trusts.
The flaws “don’t allow an unauthenticated attacker to connect to arbitrary Tailscale SSH servers,” Tailscale said, and an attacker can still reach only the machines the policy file already allows.
Tailscale SSH’s server runs only on Linux and the open-source macOS build; the attacker’s own device can be any platform.
The problem is in socket forwarding. When a permitted SSH session forwarded a connection to a Unix socket on the server, the Tailscale process checked the path but then operated as root. A timing trick let an attacker swap in a different path after that check, defeating the safeguard meant to limit which sockets forwarding could reach.
In Windisch’s own tests, forwarding to the Docker control socket produced a root shell and read the system password file, /etc/shadow, with no administrator rights. Tailscale’s bulletin describes the reach more narrowly, saying an attacker could get to root-only sockets such as the Docker socket or the tailscaled local API.
In 1.104.4, Tailscale changed the server to carry out forwarding as the logged-in user rather than as root, and to rely on the operating system’s own file permissions in place of its earlier path check. The release covers 4 security bulletins:
- TS-2026-014: the SSH socket-forwarding flaws above, which let a permitted session reach root-only sockets such as the Docker socket or the tailscaled local API.
- TS-2026-015: a way for a permitted SSH session to use up a server’s memory and crash the Tailscale process, cutting all Tailscale networking on that node.
- TS-2026-016: a flaw in tailscale serve where a forward to a Unix socket could reach the tailscaled local API, giving remote control of the node, plus a related socket-swap issue.
- TS-2026-017: a flaw where, with TLS serve and 2 or more mounts, one request could receive another mount’s permission headers.
What to Do
Users of Tailscale SSH should update to version 1.104.4 or later. If you cannot update a server yet, you can turn off SSH forwarding on it by setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service, which Tailscale says turns off forwarding without disabling Tailscale SSH and blocks several of the more serious findings.
Tailscale also recommends reviewing SSH access rules so that only the users and devices that need access have it.
Tailscale suggests using SSH check mode, which requires a user to sign in again before a session starts, for sensitive systems. Check mode does not stop these forwarding flaws: it guards the start of a session, whereas the forwarding occurs within a session that has already been approved.
If a server may already have been compromised, Windisch’s report says the fix alone is not enough. A stolen device key stays valid until the device is deleted at the control plane, because reimaging the machine does not revoke it. Tailscale’s notices do not cover this case.
The picture is worse on headscale, the self-hosted control server. On headscale, SSH forwarding is granted on every accepted session and cannot be turned off in the policy, so Windisch’s report says every SSH grant there should be treated as giving root. The newest headscale release, version 0.29.5 from October 13, does not fix the reported issues.
Is It a Worm?
Windisch called the chain “wormable.” In her tests, one compromised device could spread to every device the policy allowed, with no passwords, no stolen keys, and no user action, in under a second per step.
Two controls stopped the spread in those tests. Writing access rules as single device-to-device pairs held it back, and binding device keys to hardware such as a TPM kept a stolen identity from being reused elsewhere.
Tailscale rejected the worm description. The findings do not describe self-replicating malware that spreads between machines on its own, the company said, but lateral movement limited to the connections a policy file already allows.
It called the privilege-escalation problems “serious security issues,” said it had reproduced the main ones, and added that it is still working out which configurations are affected.
Disclosure and Earlier Fixes
As of publication, the 4 bulletins carry no CVE identifiers or severity scores, and none state the oldest affected version. The report also covered Tailscale’s app connectors and its serve and funnel features.
Tailscale said the app-connector finding is in conn25, an experimental feature it has not released, and that the connectors customers use today are not affected. Of 5 serve and funnel findings, it fixed 3 and said the other 2 work as designed.
Windisch published the report without coordinating the release with Tailscale first, which she has described as “reported but not coordinated.” Tailscale said it received the report on the morning of Saturday, October 24, about 2 hours before Windisch published it, and that its engineers were already looking at the same parts of the code.
Neither Tailscale nor the report says the flaws have been used in real attacks. The proof-of-concept code is not public, and Windisch said she gave it only to Tailscale’s security team.
The report is the latest in a run of fixes in the same part of Tailscale this year. In June, Tailscale fixed a separate flaw in Tailscale SSH’s Unix-socket forwarding that let an unprivileged user reach a privileged socket, in version 1.98.9.
