Vulnerabilities

Tailworm: unpatched Tailscale SSH flaws could give root on a tailnet

Tailworm report claims one compromised device can reach root on other servers via Tailscale SSH. No CVE or patch yet: how UK teams should harden.

Network mesh graphic with the headline Unpatched Tailscale SSH flaws risk root access

A researcher has published 11 unpatched findings in Tailscale and the self-hosted headscale server, saying one compromised device can use Tailscale SSH to reach root on other machines in a tailnet. There is no CVE, bulletin or fixed release yet, so UK teams that use Tailscale for remote administration should tighten their SSH rules this week.

What happened

On 25 October 2026 Erica Windisch of Cyberdione Labs released a report titled “Tailworm”. It describes 11 problems found during lab testing from 22 to 24 October against Tailscale client 1.104.2 and headscale 0.29.5, the open-source control server some organisations run instead of Tailscale’s hosted service.

The headline finding concerns Tailscale SSH, the feature that lets the Tailscale daemon accept SSH sessions authorised by the tailnet policy rather than by keys on each host. According to the report, when a policy rule permits SSH and port forwarding is allowed, a user on one approved device can turn that session into root-level access on the target. In the lab, a chain of findings let an attacker-controlled machine join the network as a trusted server.

The disclosure was not coordinated. Windisch said on Hacker News that the issue “was reported but not coordinated”, and The Hacker News reports she sent the material to Tailscale’s security contact before publishing. Tailscale’s vice president of engineering, Mike Shaver, said 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 now fixing, adding it was “not recommending that everyone disable Tailscale SSH”, according to The Hacker News. A Tailscale engineer added on Hacker News that “we will have more details to follow”. As of this morning, Tailscale’s bulletin page lists nothing newer than TS-2026-013, on leaked eMudhra certificate keys, issued on 21 October.

The technical picture

This is not internet-facing remote code execution. Every serious scenario assumes the attacker already controls a device on the tailnet, for example through a vulnerable web application, phishing or stolen credentials. Tailworm describes what happens next: lateral movement and privilege escalation inside what many treat as a trusted management plane.

The core problem, as the researcher describes it, is that the embedded SSH server runs with root privileges and certain forwarding operations involving Unix sockets are carried out with those privileges rather than as the logged-in user. The report sets out three related routes: one forwarding direction that connects to sockets as root, another that can replace root-owned sockets, and a timing race that defeats a path check. The outcome matters more than the mechanics: an SSH grant to a non-root account may in practice behave like a grant to root.

The other findings are broader in scope but mostly narrower in exposure. They include an experimental app connector (conn25) that can let a permitted user reach unapproved destinations, including a cloud metadata service; a tailscale serve configuration that can expose the local API to remote peers; and memory and resource issues in headscale and the DERP relay client. The report admits some results were checked against source code only.

The “wormable” label is where opinion splits. In the lab, the researcher says spread to every policy-permitted device was automated and took under a second per hop, with no passwords or user interaction needed. Some Hacker News commenters argue it is not a worm in the traditional sense, since it needs an existing foothold. Tailscale has not confirmed the claims, nobody has publicly reproduced them and no proof-of-concept has been released. Two factors limited spread in testing: SSH rules that pair one source with one destination, and device keys held in a TPM or Secure Enclave. On tailnets using Tailnet Lock, the final enrolment step was not completed.

Checklist of six steps to harden Tailscale SSH while the Tailworm findings remain unpatched

Why it matters for UK organisations

Tailscale is a popular choice for small UK IT and DevOps teams supporting hybrid staff, cloud workloads and a few on-premises servers. In many SMEs, managed service providers and engineering-led firms, the tailnet has quietly replaced the VPN and the bastion host, making its access policy the real perimeter for administrative access.

The finding cuts against the assumption that Tailscale SSH rules restricted to a non-root user are low risk. If those rules are written broadly, for example granting a whole group or tag access to every server tagged “prod”, one compromised laptop or build runner could become root on the lot. For Cyber Essentials organisations this sits squarely in user access control and secure configuration: anything that effectively grants admin rights must be treated as such.

Self-hosters face a sharper version of the problem. According to the researcher, forwarding cannot be switched off in headscale 0.29.5, so every SSH grant there should be considered root-equivalent until a fix lands. No headscale release notes yet mention these findings.

Expert view

In my experience, mesh VPNs are a gift on an internal test. When we land on a developer workstation, we check what the overlay network lets it reach, and it is usually far more than intended. Tailworm does not change that lesson; it sharpens it by suggesting that “SSH as a normal user” may not be the boundary people think it is.

Balance is needed. The report is long, unverified by third parties and was released without a fix, which some practitioners regard as poor disclosure. Equally, Tailscale’s leadership has acknowledged problems in the same areas, and the company fixed related SSH and socket bugs earlier this year, including TS-2026-004. The sensible stance: assume the core SSH finding is real, plan for a patch and do not disable remote access without a fallback.

What to do now

  1. Inventory Tailscale SSH use. Identify which devices advertise SSH and which policy rules grant it. Where SSH is not needed, disable it on the device, after confirming you have another way in.
  2. Rewrite SSH rules as tight pairs. Replace group-wide or tag-wide grants with single source-to-destination rules, and never permit privileged target accounts. This maps directly to Cyber Essentials user access control.
  3. Deny port forwarding in each rule on the hosted service where it is not required. On headscale, treat every SSH grant as root access.
  4. Remove unused features. Strip app connector rights wherever they are unused and delete any tailscale serve forward pointing at a Unix socket. This is Cyber Essentials secure configuration in practice.
  5. Enable Tailnet Lock and node-key expiry, and use hardware-bound device keys where your platforms support them.
  6. Prepare incident steps. Remove any compromised machine from the tailnet admin console or headscale; rebuilding the host alone leaves copied keys valid. Rotate Tailnet Lock signing keys if a signing node was affected.
  7. Watch for the fix. Monitor Tailscale’s bulletins and headscale releases, and update clients quickly once a patch appears.

SSH check mode adds a login step but does not fix the escalation.

Bottom line

Tailworm is a post-compromise problem, not a reason to rip out Tailscale, and its most dramatic claims remain unverified. But the core message is uncomfortable and plausible: broad SSH grants on a tailnet may be root grants in disguise. Until Tailscale ships a fix, UK organisations should tighten their access rules and treat their mesh network policy with the same seriousness as a firewall rulebase.

Sources

Related Posts