A new report called Tailworm claims that a single hacked device on a Tailscale network can gain root access on other servers it reaches. Two conditions apply: Tailscale SSH must allow port forwarding, and the attacker must already control a device the network’s access rules permit to connect to the target.
Erica Windisch of Cyberdione Labs published Tailworm on October 25 after three days of lab testing on Tailscale 1.104.2 and headscale 0.29.5, a self-hosted server some networks use instead of Tailscale’s hosted service. No real networks were attacked. At publication, Tailscale had issued no security bulletin, CVE identifier or fixed version.
Tailscale Responds to Tailworm
Mike Shaver, Tailscale’s vice president of engineering, wrote on Reddit that the company had received the report, was already examining the same areas with outside security specialists, and had found issues it was fixing.
On October 27, Tailscale published an investigation and remediation update calling the problems “serious security issues.” Most involve privilege escalation, where an authorized Tailscale SSH user “may be able to perform actions beyond the permissions of their configured local user, including potentially gaining elevated privileges.”
Fixes for most issues were in final testing, and the company said it was “targeting a release within the next 24 hours.” No fixed versions or CVEs have been named. A security advisory covering confirmed vulnerabilities, affected versions, and configurations will follow the patch, then a technical write-up.
Tailscale repeated that it is “not recommending that everyone disable Tailscale SSH,” since exposure depends on permissions and configuration, which it is still verifying.
How the Tailscale SSH Attack Works
Unlike a normal SSH server, Tailscale SSH identifies the connecting device rather than checking a password or key, and one access rule decides whether that device may open a session. The attack therefore needs no stolen credentials, only a first foothold gained through a vulnerable web app, poisoned package, phishing or stolen logins. Tailscale does not create that foothold.
In the lab, standard port forwarding made the root-level Tailscale process connect to a root-only system socket, yielding root and the system password file almost instantly without administrator rights. A second method swapped a root-owned socket for the attacker’s, enabling direct root commands against certain services.
A third raced a file-path safety check between checking and use, captured a device-enrollment key and joined an attacker’s machine to the network as a trusted server. That chain completed only where Tailnet Lock was off; with it enabled, secrets were captured in transit, but the final step failed.
Is Tailworm Truly Wormable?
Windisch calls the result “wormable.” In the lab, one compromised device spread to every device the rules allowed, in under a second per step, with no passwords, keys or user action. The report says “the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed.” Rules written as single source-to-destination pairs stopped the spread on their own, and device keys tied to a TPM or Secure Enclave also limited it. Some researchers question the “wormable” label, while others call the root finding serious.
The SSH flaw is one of 11 findings, which also cover app connectors, the serve feature, the DERP relay and headscale. No other researcher has reproduced the findings, and Tailscale has not confirmed every specific claim.
The proof-of-concept code went only to Tailscale’s security contact. Windisch described the disclosure on Y Combinator HN as “reported but not coordinated,” and one commenter there called publishing without first reporting to Tailscale irresponsible.
Locking Down Tailscale SSH Before the Patch
On Tailscale’s hosted service, forwarding can be switched off per rule. On headscale 0.29.5, it cannot, so the report says every SSH grant there should be treated as root on the target. Steps from the report and Tailscale include:
- Write access rules as single source-to-destination pairs and remove broad identity or tag grants.
- Set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart, which disables forwarding without turning off Tailscale SSH.
- Remove unneeded app connector permissions and any tailscale serve forward pointing at a Unix socket.
- Enable node-key expiry and automatic updates.
- Delete compromised devices at the control plane, since reimaging does not revoke copied keys.
- Enable SSH check mode, which adds a login barrier but does not fix the escalation.
