Researcher publishes 11 unpatched Tailscale and headscale flaws, including root escalation through Tailscale SSH

TLDR

• Erica Windisch's Tailworm report claims a compromised device can reach root on other servers through Tailscale SSH port forwarding.¹²
• No CVE, fixed version or independent reproduction exists; the findings come from lab tests of Tailscale 1.104.2 and headscale 0.29.5.¹²
• Tailscale's engineering VP says it has found issues to fix but is not recommending everyone disable Tailscale SSH.¹

Security researcher Erica Windisch of Cyberdione Labs published a report called Tailworm on 25 October, describing 11 unpatched findings in Tailscale and in headscale, the self-hosted control server some networks use instead of Tailscale's hosted service.¹² Its central claim is that when Tailscale SSH allows port forwarding, a device an attacker already controls can reach root on any target the access rules let it connect to, without stolen passwords or keys.¹² The report says testing ran from 22 to 24 October in a lab against unmodified Tailscale 1.104.2 and headscale 0.29.5, not against real networks.¹²

The Hacker News describes three lab chains. In the first, ordinary SSH port forwarding makes the root-level Tailscale process connect to a socket only root should reach, giving root and access to the system password file.¹ In the second, the attacker replaces a root-owned socket with their own to run commands against certain services.¹ In the third, a race condition defeats a file-path safety check and captures a device-enrolment key, which was used to join an attacker's machine to the network as a trusted server; that step completed only on networks without Tailnet Lock enabled.¹ Windisch calls the result wormable and says one compromised device could spread to every device the access rules allow, in under a second per step; The Hacker News stresses that this was measured in a lab and that some researchers have publicly questioned the "wormable" label.¹² The report says access rules written as single source-to-destination pairs, and device keys bound to hardware such as a TPM or Secure Enclave, held the spread back.²

The SSH issue is one of 11 findings. Windisch told The Hacker News that an app connector finding in the experimental conn25 feature "may be more impactful to some organizations": it lets a permitted user send traffic to destinations the security team never approved, including a cloud provider's metadata service, which can hand out server credentials.¹ The report also lists unauthenticated resource exhaustion in headscale, unbounded memory use in the DERP relay client and an authorisation race in tailscale serve.² On headscale 0.29.5, SSH forwarding cannot be turned off, so the report says every SSH grant there should be treated as giving root on the target.¹²

As of The Hacker News's report, Tailscale had issued no security bulletin, CVE or fixed version. Mike Shaver, Tailscale's vice president of engineering, wrote on Reddit that the company had received the report, had already been examining the same areas with outside specialists and had found issues it is working to fix, according to The Hacker News.¹ He said Tailscale is still working out which setups are affected and is "not recommending that everyone disable Tailscale SSH."¹ Tailscale has not confirmed the report's specific technical claims, no other researcher has publicly reproduced them, and the proof-of-concept code is not public.¹

The two accounts of disclosure differ in emphasis. Windisch describes it as "reported but not coordinated" and told The Hacker News she sent the report and proof-of-concept code to Tailscale's security contact the Saturday before publication.¹ Her note on the report site says she believes infrastructure is vulnerable today and that rapid awareness will speed remediation.² A commenter on Hacker News called publishing without first reporting irresponsible.¹

Pending a fix, The Hacker News lists steps drawn from the report and Tailscale's own advice: write SSH rules as single source-to-destination pairs and remove broad identity or tag grants, turn off SSH port forwarding per rule on the hosted service, remove app connector permissions from devices that do not need them, remove any tailscale serve forward pointing at a Unix socket, enable node-key expiry, and delete a compromised device at the control plane because reimaging does not revoke copied keys.¹ These are precautions, not vendor-endorsed fixes.¹

Why it matters: teams running Tailscale SSH or headscale have no patch to apply and can only tighten access rules, while the technical claims rest on one researcher's lab results that Tailscale has not confirmed.¹²