Cybersecurity firm **Cyberdione Labs** has released a report, dubbed "Tailworm," outlining a concerning vulnerability within **Tailscale** networks. The findings, published by researcher **Erica Windisch** on October 25, demonstrate how a compromised device on a **Tailscale** network, under specific **Tailscale SSH** configurations, could facilitate root access to other servers it can reach. ## The 'Tailworm' Vulnerability Explained The attack hinges on two primary conditions: **Tailscale SSH** being configured to allow port forwarding, and an attacker already having control over a device permitted by the network's access rules to connect to the target. **Windisch** conducted tests on **Tailscale** version 1.104.2 and **headscale** version 0.29.5 (a self-hosted alternative to **Tailscale**'s service) over three days in a lab environment. Crucially, this vulnerability does not require stolen passwords or SSH keys. Instead, it leverages an initial foothold on a device, which **Windisch** notes can be achieved through common attack vectors like vulnerable web applications, poisoned software packages, phishing, or stolen login details. **Tailscale** itself does not create this initial compromise. ## Technical Breakdown of the Attack Chain **Windisch** demonstrated the exploit in several stages: 1. **Privilege Escalation via Port Forwarding**: Using standard SSH port forwarding, an ordinary session could force the root-level **Tailscale** process to connect to a system socket typically only accessible by root. This immediately granted root access, allowing the reading of system password files without administrator rights. 2. **Direct Root Command Execution**: A second method involved replacing a root-owned socket with an attacker-controlled one, enabling direct root command execution against specific services. 3. **Bypassing Safety Checks and Network Expansion**: A third, more advanced technique exploited a race condition to bypass a safety check designed to limit file access. This allowed the capture of a key used to enroll new devices, subsequently enabling an attacker's machine to join the network as a trusted server. This final step was successful only on networks where **Tailscale**'s **Tailnet Lock** feature was not enabled. While secrets were captured in transit on networks with **Tailnet Lock**, the final enrollment step was prevented.  ## 'Wormable' Potential and Official Response **Windisch** describes the overall result as "wormable," illustrating in lab tests how one compromised device could spread to every device allowed by access rules in under a second per step, without passwords, stolen keys, or user interaction. The report states, "the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed." **Tailscale**'s Vice President of Engineering, **Mike Shaver**, has publicly acknowledged receipt of the report on Reddit, stating the company was already investigating similar areas with external security specialists and is working on fixes. **Shaver** also clarified that **Tailscale** is not currently recommending disabling **Tailscale SSH** entirely, as the affected configurations are still being determined. It's important to note that as of this publication, **Tailscale** has not issued a security bulletin, a **CVE** identifier, or a fixed version. The findings remain based solely on **Windisch**'s report, and other researchers have not publicly reproduced them, nor has **Tailscale** confirmed the specific technical claims. **Windisch** stated that the proof-of-concept code has been provided directly to **Tailscale**'s security contact. This report follows a series of past security fixes by **Tailscale** related to **Tailscale SSH** and server socket handling, including a fix in version 1.98.9 for SSH Unix socket forwarding reaching a privileged socket. ## Beyond SSH: Other Findings The "Tailworm" report encompasses 11 findings, extending beyond **Tailscale SSH** to include **Tailscale**'s app connectors, its `serve` feature, the **DERP relay**, and **headscale**. **Windisch** highlighted that while the SSH privilege escalation is concerning, the app connector finding, particularly in the experimental `conn25` feature, "may be more impactful to some organizations." This app connector vulnerability could allow a permitted user to send traffic to unapproved destinations, including cloud provider metadata services, which can expose server credentials. ## Immediate Mitigation Steps for Users Given the absence of a patch, administrators are advised to implement the following configuration changes, which align with both the report's recommendations and **Tailscale**'s advice: * **Review Tailscale SSH Access Rules**: Configure rules as single source-to-destination pairs, explicitly naming one device and one target. Remove broad rules that grant access by identity or tag, as per-pair rules were found to halt spread in testing. * **Disable SSH Port Forwarding**: Where possible, turn off SSH port forwarding. On **Tailscale**'s hosted service, this is a per-rule setting. For **headscale** version 0.29.5, where it cannot be disabled, every SSH grant should be treated as conferring root access on the target. * **Remove App Connector Permissions**: Limit app connector permissions to only those devices that explicitly require them. * **Remove `tailscale serve` Unix Socket Forwards**: Eliminate any `tailscale serve` forwards that point to a Unix socket. * **Enable Node-Key Expiry**: Activate node-key expiry to limit the validity period of potentially stolen device keys. * **Compromised Device Protocol**: If a device is compromised, delete it immediately from the control plane. Reimaging the machine alone is insufficient, as an attacker may have already exfiltrated keys. **Tailscale** also suggests enabling SSH check mode, which introduces an additional login step, and enabling automatic updates. While check mode adds a barrier, it does not directly fix the underlying privilege escalation vulnerability.