Tailworm: 11 Unpatched Tailscale Flaws, Including Root Access via Tailscale SSH

With Tailworm, researcher Erica Windisch disclosed 11 security flaws in Tailscale and Headscale without waiting for them to be fixed. Here’s what you need to know.

This set of security flaws, nicknamed TailWorm, was published on tailworm.com by Erica Windisch, now at Cyberdione Labs. Her audit, conducted from October 22 to 24, 2026, covered the Tailscale client v1.104.2 and Headscale v0.29.5, the self-hosted control server. In total, she found 11 vulnerabilities, including 6 rated high severity.

As a reminder, Tailscale is a WireGuard-based mesh VPN. Every device connected to this private network, called a tailnet, communicates directly with the others, without a central VPN server or any ports to open on the firewall. A control server, hosted by Tailscale or replaced by Headscale in a self-hosted setup, distributes keys, routes, and access rules (ACLs), but traffic does not pass through it.

The Tailscale SSH feature, mentioned later in this article, is used to connect to servers over SSH without managing SSH keys or passwords. The Tailscale network decides who is allowed to access a resource. Authentication no longer relies on SSH keys, but on the device identity and an access policy rule. If you are new to the solution, I’ve published a complete guide to Tailscale, the WireGuard-based mesh VPN.

Tailscale SSH: from one compromised machine to the rest of the network

With OpenSSH, the process handling a session drops root privileges once authentication is complete, keeping only the privileges of the logged-in user. Tailscale SSH, however, is integrated into tailscaled, which runs as root. According to the researcher, Unix socket forwarding (ssh -L and ssh -R) is therefore performed with root privileges. A standard user can thus make the daemon communicate with a root-only socket, such as Docker’s, and obtain root privileges on the machine.

The allowlist of permitted paths (home directory, /tmp, /run/user) is bypassed through a race condition (TOCTOU): the path is checked, then resolved again at the time of the operation. To exploit this security flaw, the attacker launches a loop in their SSH session that renames the targeted path about 170,000 times per second. They eventually manage to change it between the check and the operation, which then applies to a root-only target.

That’s not all. By hijacking the tailscaled control socket, the researcher captured an enrollment key and made a rogue machine join the tailnet, with Tailnet Lock disabled by default. Thanks to this change and automatic propagation, that modification reached every device allowed by the SSH policy in less than one second. Hence the name Tailworm.

However, the attacker must already control a trusted device in the tailnet to exploit this security flaw and potentially take over all the other devices. The other findings affect:

• App connectors (conn25): this experimental feature lets an authorized device reach any destination, including the cloud metadata service.
• Headscale: an instance exposed to the internet can be hit by a denial-of-service attack that blocks the enrollment of new devices.
• Tailscale Serve: a TCP forwarding rule configured to the tailscaled socket exposes the node’s local administration API.

A non-coordinated disclosure...

The researcher, who has no ties to Tailscale, chose to disclose these security flaws as zero-days: no patches are available. "The infrastructure is vulnerable today," she says, betting on rapid awareness to speed up remediation. She also states that the issues were reported to the vendor, but without coordinating public disclosure with patch publication.

As of October 26, 2026, Tailscale still has not published a security bulletin on the matter, no CVE has been assigned, and the latest stable version remains 1.104.2.

Fixes are reportedly in preparation, according to recent activity in Tailscale’s GitHub repository. The first, merged into the code on October 25, fixes a Tailscale Serve flaw related to permissions passed to published applications. The second, still under review, addresses SSH forwarding: it would no longer run with root privileges, but with those of the connected user, as OpenSSH does.

However, no version of Tailscale includes them yet.

How to reduce the risks right now

While waiting for a security fix, here are a few ways to reduce the risk:

• Pair-based SSH rules: one specific source to one specific destination, never at the scale of an identity or a tag. That is what helps stop propagation.
• Disable forwarding: on the SaaS service, turn off forwarding in each SSH rule. On Headscale, the policy does not allow it, but tailscaled reads the TS_SSH_DISABLE_FORWARDING=true variable: add it to the /etc/default/tailscaled file and restart the service to reject any forwarding on the node.
• Turn off Tailscale SSH: if you do not use it, the sudo tailscale set --ssh=false command disables the feature.
• Time-limited identities: enable node key expiration on servers.

If you followed my tutorial to deploy Headscale and self-host your Tailscale control server, also limit its exposure.

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio