Tailscale SSH flaws could enable root access across networks
Tailscale SSH flaws documented by a Cyberdione Labs researcher could allow an attacker controlling one device to obtain root access, the highest level of system control, on other permitted servers. The attack requires Tailscale SSH, a remote login feature based on Secure Shell, to allow port forwarding, which lets a connection carry traffic to another local or remote destination. The compromised device must also be authorised by the network's access rules to connect to its target.
The findings appeared on October 25 in a report titled Tailworm. The researcher tested Tailscale 1.104.2 and headscale 0.29.5, a self-hosted server used by some organisations instead of Tailscale's hosted service. Testing took place over three days in a laboratory. The report does not describe attacks observed on production networks, and no other researcher has publicly reproduced its findings. At publication, there was no security bulletin, CVE identifier or fixed version, and Tailscale had not confirmed the individual technical claims.
Tailscale said publicly that it had received the report and was already examining the same areas with outside security specialists. Its vice president of engineering said the company had identified issues it was working to fix but was still determining which configurations were affected. The company was not advising every customer to disable Tailscale SSH.
The risk comes from how Tailscale SSH authorises sessions. A conventional SSH server normally checks a user's password or cryptographic key. Tailscale SSH instead identifies the connecting device and uses an access rule to decide whether that device may start an SSH session. The reported attack therefore does not require the attacker to steal an SSH password or key. It still requires an initial compromise, which the report says could come through a vulnerable web application, a malicious software package, phishing or stolen login credentials. Tailscale itself does not provide that first foothold.
In the first laboratory test, standard SSH port forwarding caused the Tailscale process, which runs with root privileges, to connect to a system socket. A socket is a local communication channel used by software, and this particular one should have been accessible only to root. The session obtained root access and read the system password file without administrator rights. In another method, the researcher replaced a root-owned socket with one controlled by the attacker, enabling direct root commands against certain services.
A third technique exploited a timing gap between checking a file path and using it. By changing the target during that brief interval, the test bypassed a safeguard intended to restrict which files forwarding could reach. The resulting chain captured a device enrolment key and used it to add an attacker-controlled machine to the network as a trusted server. That complete chain worked only where Tailnet Lock was not enabled. With Tailnet Lock active, the secrets were captured while moving between systems, but the final enrolment step was not completed.
The researcher described the chain as wormable because one compromised device could move to every other device allowed by the access rules, without further passwords, stolen SSH keys or user interaction. In the laboratory, each step took less than a second. Some researchers who reviewed the report have questioned whether wormable is the right description, while others have characterised the root-access result as serious. There is no evidence in the report that this spread has occurred on real networks.
Two controls stopped or constrained the laboratory chain. Access rules limited to a single named source and destination prevented further spread. Device keys bound to hardware, such as a Trusted Platform Module (TPM) or Secure Enclave, also limited the attack. A TPM is a protected component that can keep cryptographic material tied to a particular device.
Administrators have different options depending on their deployment. Tailscale's hosted service allows port forwarding to be disabled for each rule. Headscale 0.29.5 does not provide that option, so the report recommends treating every SSH permission on that version as potentially granting root on the destination. Tailscale also recommends SSH check mode, which adds a login approval step, and automatic updates. Check mode creates another obstacle but does not correct the reported privilege escalation.
The SSH issue is one of 11 findings in Tailworm. The report also examines app connectors, the serve feature, the DERP relay that carries traffic between devices, and headscale. One app connector issue in the experimental conn25 feature allegedly permits an authorised user to send traffic to destinations the security team did not approve. Those destinations can include a cloud provider's metadata service, an internal service that may supply server credentials. The researcher said this issue could be more consequential for some organisations than the SSH escalation.
Proof-of-concept code has not been made public. The researcher said it was sent privately to Tailscale's security contact with the report on the Saturday before publication. The disclosure was described as reported but not coordinated, and its timing drew public criticism. The researcher also said earlier architectural concerns had been raised with Tailscale's chief executive, and that a file hash was posted publicly alongside advice to disable Tailscale SSH.
The findings follow earlier work in the same component. During 2026, Tailscale fixed several SSH and server socket-handling problems, including a flaw that allowed SSH Unix socket forwarding to reach a privileged socket. That issue was addressed in version 1.98.9.
Until fixes and affected configurations are confirmed, administrators should replace broad identity-based or tag-based SSH rules with single-device, single-target rules, disable forwarding wherever the service permits it, remove unnecessary app connector permissions and delete any tailscale serve forwarding rule aimed at a Unix socket. Node-key expiry should be enabled so copied device keys do not remain valid indefinitely. If a device is compromised, it should be deleted through the control plane, the central service that manages network membership, because reinstalling the device does not revoke keys an attacker may already have copied.
For readers assessing the wider IT implications of this issue, AEU-I offers security-first IT, infrastructure and consulting. Organisations should document any temporary restrictions they introduce and continue watching for a vendor bulletin, confirmed affected configurations and a fixed release.