Researcher Erica Windisch, from Cyberdione Labs, published on Sunday 25 October Tailworma report with 11 problems in Tailscale 1.104.2 and in headscale 0.29.5the open source control server that some networks use in place of the company-hosted service. The first group concerns Tailscale SSH configured to allow port forwarding: those who control only one device that the access rules authorize to connect to a server can, according to the report, obtain the root on that server. Windisch tested everything in the lab, on unmodified software, between October 22nd and 24th.
There is no fix yet. At the time of writing, Tailscale has not published a security bulletin, a CVE identifier, or a release that addresses the issues described, and the most recent bulletin listed, TS-2026-013, concerns eMudhra’s compromised TLS certificates. The changelog also stops at 1.104.2, the version tested by the researcher.
Recent Tailscale vulnerability reports
by u/saver at Tailscale
However, the company responded in public. Mike Shaver, vice president of engineering, wrote on Reddit that Tailscale received the report, was already examining the same areas with outside specialists, and found issues that it is working to fix. Shaver adds that the company is still determining which configurations are affected and that it “does not recommend turning off Tailscale SSH for everyone.” All findings are based on the report alone: it appears that no other researcher has reproduced them in public, Tailscale has not confirmed individual technical claims, and the proof of concept code is not public, because Windisch only sent it to the company’s security contact.
Tailscale SSH: From hacked device to root
Tailscale SSH does not verify the password or key of the connecting user. It identifies the device via the WireGuard layer, and a single access rule decides whether that device can open an SSH session to the target server. For this reason the attack does not require passwords or stolen keys: a point of support on a single device authorized, which the report indicates in the usual ways (a vulnerable web application, a poisoned software package, phishing, stolen credentials) and of which Tailscale is not the cause. Tailscale SSH is enabled on a per-node basis, but according to the report it is often enabled fleet-wide, and the feature must allow port forwarding.
In the laboratory, Windisch demonstrated the problem in stages. With normal SSH port forwarding, an ordinary session had the Tailscale process, running as root, connect to a system socket reserved for root: the test got root and read the system password file almost immediately, without administrator rights. A second method replaced a socket owned by root with one owned by the attacker, resulting in direct execution of commands as root on some services; among the communication channels involved, the report mentions those of the container platform and the init system. A third method bypassed the check that limits the files reachable by the forwarder, exploiting a race condition between the time the path is checked and the time it is used.
With the third method the chain went further. It captured a key used to register new devices and used it to let an attacker’s machine into the network as tagged server legitimate looking, with routes automatically approved. The final pass succeeded from top to bottom only on the nets where Tailnet Lock it was not active, i.e. in the default configuration. Where the feature is active, the necessary secrets have been captured in transit, but the last step has not been completed.
Windisch calls the overall result “wormable”, capable of propagating itself: in the laboratory a compromised device has spread to every device that the access rules allow, without passwords, without stolen keys and without user actions, in less than a second per jump. In the report the formula is that “the mesh network transforms a normal point of support into privileged access to the entire device fleet, at the speed of machines”. The propagation was measured in the laboratory and not observed on real networks. The report indicates two brakes: access rules written as single origin-destination pairswhich alone stopped the spread, and the Hardware-related device keyssuch as TPM or Secure Enclave. Some researchers have publicly contested the definition of “wormable”, others have judged the result on the root to be serious.
App connector, headscale, DERP and serves
In the’app connectorthe experimental function conn25 of Tailscale, the connector translates traffic to attacker-chosen destinations without validating them, and network ACLs are never consulted for the actual destination. All it takes is a device that has been granted connector capability to reach the cloud’s metadata service, which can deliver server credentials, internal local networks, and, in Kubernetes, every service in the cluster. Windisch said privilege escalation on SSH is concerning, but that the app connector issue “may be more impactful for some organizations.”
On headscale the report describes resource exhaustion without authentication: memory grows and the cache is emptied, eventually sending the control server into a reboot loop and blocking new devices from entering the entire organization. The attacker just needs the server to be reachable from the internet, without any account. In the client DERP present in every Tailscale agent, the response of a malicious relay is read without limits and leads to exhaustion of the agent’s memory, but the client must be directed towards a hostile relay. In tailscale is neededTCP forwarding to a Unix socket lacks protection present in the HTTP path: if an administrator has configured that forwarding, a peer can remotely reach the node’s administrative API. Added to this is a race condition in mount point authorization, where a minority of requests bypass application checks.
Uncoordinated disclosure and countermeasures
Windisch motivates the immediate publication in the preface to the report: in his opinion infrastructure is vulnerable today, and making flaws known early speeds up the fix on affected devices. The analysis concerns only open source software distributed under the BSD-3 license and without guarantees, and the researcher declares that she has no relationship with Tailscale Inc. and has not been hired or paid by it. In the same text he argues that the design choices of Tailscale and headscale remove layers of authentication and replace daemons like OpenSSH, which separate privileges, with a highly privileged process.
Windisch described the disclosure as “reported but uncoordinated,” and said he sent reports and proofs of concept to Tailscale’s security contact on the Saturday before publication, made the file hash public and recommended turning off Tailscale SSH, and raised his reservations about the company’s architecture with the CEO earlier.
Tailscale had already intervened in the same perimeter this year. Version 1.98.9 closed, among other things, a case of SSH Unix socket forwarding reaching a privileged socket and a case of hyphenated username: connecting as “-i” to a Linux node resulted in a root session in violation of ACLs (TS-2026-009).
Until a release or bulletin arrives, the configuration changes remain, on which the report and Tailscale’s recommendations largely coincide. SSH rules should be written as single origin-destination pairseliminating those that are wide by identity or tag: it is the only control that stopped the propagation in the laboratory. SSH forwarding should be disabled where possible: on the Tailscale hosted service it is a per-rule setting, while on headscale 0.29.5 it cannot be disabled, and any SSH permissions should be treated as equivalent to root on the target server. Restricting SSH to unprivileged accounts is not enough, according to the report, because the attacks start from unprivileged accounts.
App connector permissions should be removed from devices that don’t need them, and tailscale forwarding is needed towards removed Unix sockets. For server fleets the report indicates the expiration of node keys. A compromised device must be eliminated from the control plane: reinstalling the machine does not revoke the keys that the attacker may have already copied. On headscale the report suggests memory limits, reboot supervision and limitation of recording frequency. Tailscale also recommends enabling SSH check mode, which adds a login step before the session, and automatic updates; check mode doesn’t resolve privilege escalation, it just adds a barrier. Where Tailscale SSH is not needed, tailscale set –ssh=false it deactivates it, but as the Tailscale documentation warns, it is best to first check that you have another access to the server, otherwise you can lose it.
