Tailworm: Tailscale SSH flaws give root from one breached node

Over the weekend of 24–25 October 2026, Cyberdione Labs published details of 11 vulnerabilities in Tailscale, the WireGuard-based mesh VPN, and in headscale, the open source control server that organisations can host themselves. The researchers call them collectively Tailworm. They found them during an audit of Tailscale 1.104.2 and headscale 0.29.5 and reproduced them in a lab on released, unmodified software (BleepingComputer).

The disclosure happened before any patches existed. According to SecurityWeek, this drew criticism on social media, while Cyberdione Labs founder Erica Windisch argues that rapid awareness speeds up remediation and that the flaws were found “with low effort”. At the time of the reports no CVEs had been assigned, and neither Tailscale nor the report mentions in-the-wild exploitation (SecurityWeek).

The main issue: Tailscale SSH

Tailscale SSH is the SSH server embedded in tailscaled: it runs as root and grants access based on device identity and tailnet policy, without passwords or keys. According to the report cited by both outlets, Unix socket forwarding (ssh -R and ssh -L) performs path checks and file operations with root privileges. Race conditions and a missing privilege drop let an ordinary session replace, dial or delete privileged resources.

Of the six high-severity findings, four concern Tailscale SSH (SecurityWeek). Outcomes demonstrated in the lab:

• code execution as root on target servers;
• theft of enrollment keys, which can be used to add rogue devices to the tailnet;
• deletion of arbitrary files with root privileges.

The requirement is one approved device plus one SSH rule that allows forwarding. On headscale forwarding is granted automatically; on Tailscale’s SaaS service it depends on the individual rule (BleepingComputer).

A chain that spreads by itself

According to SecurityWeek, the researchers showed that the flaws are wormable: no user credentials are needed, and an automated attack chaining the bugs moved from machine to machine across every server reachable via Tailscale SSH under the policy, at under a second per hop and with no user interaction. The entry point can be any compromise of a node: phishing, a vulnerable web application, a malicious software package. The Hacker News headline describes the same scenario: a hacked device reaching root on other servers.

Relevant MITRE ATT&CK techniques (our mapping): T1021.004 (SSH as a remote service), T1068 (exploitation for privilege escalation) and T1210 (exploitation of remote services) for propagation.

The other flaws

The report also describes (BleepingComputer, SecurityWeek):

• app connectors (conn25, an experimental feature): traffic is translated to attacker-chosen destinations without validation, and ACLs are never applied to the true destination. With a device granted the connector capability, an attacker can reach cloud metadata services (credential theft, T1552.005), internal LANs and, in Kubernetes, every cluster service;
• headscale: unauthenticated resource exhaustion (memory growth, cache eviction) that anyone who can reach the server can trigger. Result: a control-server crash loop and blocked onboarding of new devices across the whole organisation;
• DERP client (the relay component in every agent): unbounded read of a malicious relay’s response, exhausting the client’s memory;
• tailscale serve: TCP forwarding to a Unix socket lacks a guard that exists on the HTTP path, and a race in per-mount authorisation lets some requests through. Result: remote access to the node’s administrative API.

Tailscale’s response

Mike Shaver, VP of Engineering at Tailscale, wrote on Reddit that the company was already running its own investigation, with outside specialists, when the report arrived. According to Tailscale, most of the issues concern what happens after someone is authorised to connect: a session may be able to do more than the configured local user should. It is serious, but it is not the same as an unauthenticated attacker connecting to arbitrary machines; the impact depends on how SSH access is configured (SecurityWeek, BleepingComputer).

Tailscale does not recommend disabling Tailscale SSH and aimed to release a fixed client by Tuesday 27 October. According to SecurityWeek’s update, the company then published its full findings, the fixes it has rolled out and four security bulletins with remediation guidance. The sources do not give the fixed version number: check it in Tailscale’s bulletins. For headscale, the sources do not mention a fixed version.

Impact for European and Italian organisations

Tailscale is used for remote access by administrators, developers and suppliers: a single compromised laptop with SSH access to many servers becomes the starting point for root on all of them. Stolen enrollment keys let an attacker stay in the network even after the first device is cleaned up. For NIS2 entities, the case touches vulnerability handling and control of privileged access, including that of suppliers and maintainers. In healthcare, nodes that give access to clinical systems should be checked first.

What to do now

1. Update Tailscale clients to the version named in Tailscale’s bulletins, starting with servers that accept Tailscale SSH.
2. Disable SSH forwarding where it is not needed: set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service. Tailscale SSH stays on and, according to Tailscale, several of the more serious findings are mitigated.
3. Tighten SSH policies to the users and devices that actually need access, at least until the analysis is complete.
4. headscale: do not expose the control server more than necessary and follow the project’s updates; remember that forwarding is granted automatically there.
5. App connectors and serve: check who holds the connector capability and which forwards to Unix sockets are configured.
6. Detection: look in the tailnet for recently enrolled, unrecognised devices, SSH sessions forwarding Unix sockets, and deleted or replaced system files. If in doubt, rotate enrollment keys.

How ARXDOME helps

ARX Sentry collects security events, software inventory and file integrity monitoring for selected folders from Linux servers: it helps you find machines running Tailscale, see their version and spot privileged access or modified system files. If a node is suspicious, ARX Shield isolates it from the network until it has been checked.

Last updated: 27 October 2026