Self-hosting

Unpatched Tailscale SSH flaw allows root escalation across networks

A new report details a critical vulnerability in Tailscale and headscale that lets attackers gain root access on target servers via SSH port forwarding, with no patch currently available.

Illustration of a network mesh with one compromised node affecting others
Illustration created for this article

Security researcher Erica Windisch published findings this week revealing a critical vulnerability in Tailscale and its self-hosted alternative, headscale. The flaw allows an attacker who has compromised a single device to escalate privileges to root on other servers within the same network. As of October 25, 2026, no official patch or CVE identifier has been released by the vendor.

What happened

The vulnerability, detailed in a report titled Tailworm by Cyberdione Labs, affects Tailscale version 1.104.2 and headscale version 0.29.5. Windisch demonstrated that if Tailscale SSH is configured to allow port forwarding, an attacker with control over one permitted device can exploit the system to gain root access on target machines. The attack does not require stolen passwords or keys, as Tailscale SSH authenticates devices rather than users. Instead, it relies on an initial foothold gained through common vectors like phishing or vulnerable web applications.

In laboratory tests conducted over three days, the researcher showed that the exploit could spread rapidly across the network. The process involves using standard SSH port forwarding to access system sockets reserved for root, allowing the attacker to read sensitive files like the system password file. In some scenarios, the attacker could replace root-owned sockets to execute commands directly. The report describes the potential spread as wormable, meaning one compromised device could infect others allowed by access rules in under a second per step, though this was only observed in controlled lab environments.

Tailscale has acknowledged the report but has not yet issued a fix. Mike Shaver, vice president of engineering at Tailscale, stated on Reddit that the company is working with outside security specialists to address the issues. He noted that they are still determining which specific setups are affected and advised against disabling Tailscale SSH entirely for all users. The disclosure has sparked debate, with Windisch describing it as reported but not coordinated, while some community members criticized the public release before a patch was ready.

Key details

  • The vulnerability affects Tailscale v1.104.2 and headscale v0.29.5, specifically when SSH port forwarding is enabled.
  • Attackers can gain root access on target servers without stealing passwords or keys, leveraging device-based authentication.
  • On headscale v0.29.5, SSH port forwarding cannot be disabled, meaning every SSH grant effectively provides root access to the target.
  • The exploit chain can capture enrollment keys to join attacker-controlled machines to the network, unless Tailnet Lock is enabled.
  • Tailscale has not released a patch, CVE, or security bulletin as of October 25, 2026.
  • Access rules written as single source-to-destination pairs were the only control that stopped the spread in testing.

Background

Tailscale is a popular tool for creating secure private networks between devices, often used by developers and small businesses for remote access and internal services. It uses a mesh network architecture where devices connect directly to each other. Tailscale SSH is a feature that simplifies secure shell access by managing authentication through the Tailscale identity layer rather than traditional SSH keys or passwords. Headscale is an open-source, self-hosted implementation of the Tailscale control server, allowing organizations to run their own coordination infrastructure instead of relying on Tailscale’s hosted service.

Port forwarding in SSH allows traffic to be tunneled through an encrypted connection to access services on remote machines. While useful for development and administration, it can introduce security risks if not carefully restricted. In this case, the interaction between Tailscale’s device authentication and SSH port forwarding creates a path for privilege escalation. The term wormable refers to malware that can self-replicate and spread across a network without user intervention, which is a significant concern for network administrators managing multiple connected devices.

Why it matters

For teams running their own software, especially those using self-hosted solutions like headscale, this vulnerability poses a severe risk to infrastructure integrity. Since headscale users cannot disable SSH port forwarding in version 0.29.5, any device granted SSH access is potentially a gateway for root-level compromise on target servers. This undermines the principle of least privilege, a core tenet of secure system administration. Small and mid-sized companies often rely on these tools for ease of management, but this incident highlights the trade-offs between convenience and security control.

The lack of an immediate patch means administrators must rely on configuration changes to mitigate risk. This requires a deep understanding of network topology and access rules, which may be challenging for smaller teams with limited security resources. The potential for rapid, automated spread means that a single breach, such as a compromised laptop or server, could lead to full network takeover. This emphasizes the need for robust monitoring and strict access controls in self-hosted environments.

What you can do

  • Review and restrict Tailscale SSH access rules to use single source-to-destination pairs, avoiding broad grants based on tags or identities.
  • Disable SSH port forwarding on Tailscale’s hosted service where possible; for headscale users, assume all SSH grants provide root access.
  • Remove app connector permissions from devices that do not explicitly require them to prevent unauthorized traffic routing.
  • Delete any tailscale serve forwards that point to Unix sockets to reduce exposure to local privilege escalation.
  • Enable node-key expiry to ensure that stolen device keys do not remain valid indefinitely.
  • If a device is suspected of compromise, delete it from the control plane immediately rather than just reimaging, as keys may have been copied.

More news

All news