Critical Tailscale SSH flaws let attackers gain root access across servers

Key Takeaways

• A new report identifies critical vulnerabilities in Tailscale SSH and related components.
• Exploitation could allow attackers to escalate privileges to root and achieve lateral movement across private networks.
• Impacts Tailscale SSH, app connectors, DERP relay client, and headscale, particularly versions 1.104.2 and 0.29.5.
• No official patches or CVEs have been released by Tailscale as of the report date, but mitigation steps are available.

Critical Flaws in Tailscale SSH Expose Servers to Root Access

A recent security analysis, dubbed “Tailworm,” has unveiled significant vulnerabilities within Tailscale SSH that could enable an attacker to escalate privileges from a compromised device to gain root access on other servers within a private network. Tailscale SSH is designed to facilitate secure, peer-to-peer logins among authorized devices over a private network.

Published on October 25, 2026, by security researcher Erica Windisch of Cyberdione Labs, the Tailworm report details these critical findings. As of the report’s release, Tailscale had not publicly confirmed the vulnerabilities, issued any Common Vulnerabilities and Exposures (CVE) numbers, or released patches. The research evaluated Tailscale version 1.104.2 and headscale version 0.29.5, an open-source alternative for managing Tailscale networks, between October 22 and October 24, 2026.

Deep Dive into the Tailscale SSH Vulnerabilities

The report outlines 11 distinct findings categorized into five groups, affecting various Tailscale components including the SSH server, its “serve” and “app connector” features, the DERP relay client, and headscale. The most severe issues are concentrated within Tailscale SSH itself.

According to the report, the Tailscale SSH server operates within tailscaled, a daemon that runs with root privileges. When a user is authorized for Unix socket forwarding (ssh -L), a common feature used by services like Docker, the tailscaled process can open or replace these sockets with root permissions. In a laboratory setting, this allowed an ordinary SSH session to immediately gain root access and read sensitive files such as /etc/shadow.

Another critical finding involves remote socket forwarding (ssh -R), where an attacker could replace root-owned sockets, leading to root code execution via a command daemon. A timing vulnerability (race condition) was also identified, potentially allowing a path check to be bypassed, which in testing led to a rogue node joining the network. These high-severity flaws highlight how misconfigured or overly permissive SSH rules can be leveraged for significant compromise.

The researcher demonstrated a potent attack chain where a single compromised device could rapidly achieve root access on multiple other servers and enroll a malicious node, effectively masquerading as a legitimate server. This propagation, observed in lab conditions, occurred without needing passwords or stolen keys, moving from device to device in less than a second per hop.

Tailscale constructs a private mesh network where devices inherently trust each other based on defined policy rules. The report emphasizes that every device receives a complete list of its peers, providing an attacker with a clear map of potential targets once a foothold is established. Initial compromise vectors could include vulnerable web applications, malicious software packages, phishing attacks, or stolen credentials.

Crucially, the report notes that while Tailscale may not be the source of the initial breach, its architecture can amplify a minor compromise into widespread network access. The researcher found that granular, per-pair access rules were the only effective control for preventing this lateral spread in their tests.

Beyond SSH: App Connectors, Headscale, and Serve Features

The Tailworm report also details issues outside of the core SSH functionality. The experimental conn25 app connector feature was found to allow a device with connector permissions to direct traffic to arbitrary destinations. This capability could be abused to access cloud metadata services containing server credentials or internal services within Kubernetes clusters.

Regarding headscale, a memory exhaustion vulnerability was identified that does not require authentication. A remote attacker could deplete the control server’s memory, preventing new devices from joining the network. Additionally, the tailscale serve feature, when configured to forward traffic to Unix sockets, could inadvertently expose the local administration interface to remote peers.

A Pattern of SSH-Related Concerns

This is not the first instance of a significant SSH-related vulnerability in Tailscale this year. In July 2026, Tailscale addressed TS-2026-009, a flaw where a username beginning with a dash could cause a Linux account lookup to incorrectly return the root account. This allowed users with SSH access to bypass ACLs and open root sessions. A fix was released in version 1.98.9.

The researcher also points to a fundamental architectural difference, arguing that Tailscale SSH departs from the layered security model of OpenSSH. OpenSSH typically drops privileges before a user session begins, ensuring sessions run with the user’s specific rights. In contrast, the Tailscale SSH implementation maintains a highly privileged process throughout the session, which the report suggests increases the attack surface.

What You Should Do

Given the absence of official patches from Tailscale at this time, administrators should implement the following mitigation strategies based on the researcher’s recommendations:

• Restrict SSH Rules: Replace broad, identity-wide, or tag-wide SSH rules with highly specific per-pair grants that explicitly name both the source and destination.
• Deny Forwarding: Set forwarding to “denied” in all SSH rules where this configuration option is available. For headscale 0.29.5, where forwarding cannot be disabled, treat every SSH grant as equivalent to root access.
• Disable Unnecessary SSH: Turn off Tailscale SSH on any devices that do not explicitly require it by executing tailscale set --ssh=false. Ensure alternative access methods are confirmed before disabling to prevent lockout.
• Review App Connector Permissions: Remove app connector permissions from devices where they are not actively used.
• Secure Serve Forwards: Eliminate any serve forwards that direct traffic to Unix sockets.
• Enable Node-Key Expiry: Implement node-key expiry to limit the lifespan of device credentials.
• Compromised Device Response: If a device is suspected to be compromised, delete it from the control plane immediately. Reimaging the host is insufficient, as copied keys will not be revoked.

Readers are strongly encouraged to review the comprehensive Tailworm report directly for full details and to monitor Tailscale’s official security bulletins for any updates or official responses. While some discussions exist regarding the severity of these findings and their origins in lab tests rather than confirmed breaches, the report clearly illustrates how overly permissive access rules can transform a single point of compromise into widespread network access. Organizations utilizing Tailscale SSH should proactively review their access policies and consult Tailscale’s SSH documentation before making any configuration changes.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.