26 OCT 2026 — A security researcher has published 11 unpatched findings in Tailscale, the mesh VPN many companies use to reach their servers. The worst of them, according to the report, lets an attacker who controls one device gain root on other machines on the same network. The report, called Tailworm, was posted by Erica Windisch of Cyberdione Labs Corporation after lab testing between 22 and 24 October. As of Monday morning Singapore time, Tailscale had issued no security bulletin, CVE or fixed version in response.
The Tailworm report examines the Tailscale client v1.104.2, the current release, and headscale v0.29.5, an open-source server some organisations run in place of Tailscale's hosted control plane. Its findings fall into five classes, covering Tailscale SSH, the experimental conn25 app connector, the DERP relay client, the serve feature and headscale itself. RECATOOLS has not reproduced any of them, and Tailscale has not published its own assessment.
A privileged agent doing the user's work
The class the report rates most serious concerns Tailscale SSH, the SSH server built into tailscaled, the background agent that runs with full root privileges. When a session is allowed to forward Unix sockets, the report says, tailscaled carries out those operations itself, as root, rather than as the user who asked. Windisch rates the three findings in this group High and says they share one root cause.
The report argues that this turns an ordinary approved login into administrator control of the target machine. Windisch reports reaching root on lab servers and capturing the keys used to enrol new devices, which made it possible to add an attacker-controlled machine to the network under a trusted identity in the default configuration, where a feature called Tailnet Lock is switched off.
The report is careful about where the attack starts. Tailscale "does not create the foothold", it says. The attacker first needs a compromised device, through a vulnerable web application, a poisoned software package, phishing or stolen credentials, and an SSH policy rule that lets that device connect to others.
The claim of machine-speed spread
The report's headline claim is that the flaw can spread on its own. In the lab, it says, Tailscale SSH combined with the forwarding findings allowed automated movement to every device the access policy permitted, with no passwords or stolen keys, at "under a second per hop".
Two things limited it. Access rules written per pair, from one named device to another, bounded how far it travelled, and the report calls that "the single control that stopped it". Device credentials held in hardware such as a TPM stopped stolen identities from persisting. Everything else Windisch measured changed how quickly a defender might notice, the report says. It did nothing to the spread.
Tailscale's check mode, which makes a user sign in again before an SSH session opens, does not help here either. Forwarding happens inside a session that has already been approved, the report warns.
Why it was published without a fix
The report opens with a note in which Windisch criticises design choices in Tailscale and headscale and says "infrastructure is vulnerable today". Windisch describes the research as unpaid, done on the researcher's own systems against open-source code, and argues that publishing quickly should speed up fixes. The report does not set out a coordinated disclosure timeline or say when Tailscale was told.
Tailscale's own record shows the same area has needed fixes before. Its security bulletins page lists TS-2026-004 in June, on Unix socket forwarding that ignored symlink permissions, and TS-2026-006 and TS-2026-009 in June and July, on two separate ways Tailscale SSH could be steered into a root session against policy. All three were fixed in v1.98.9.
What Tailscale's code shows
There is activity in public. On 25 October a Tailscale developer opened a pull request titled "ssh/tailssh: route SSH forwarding through the privileged monitor". It describes moving socket forwarding into child processes that act with the logged-in user's credentials, "never by root tailscaled", which matches the fix family the report recommends. The pull request was still open and unmerged when RECATOOLS checked, and it cites an internal ticket, not the report, so it cannot be read as a confirmed response.
Of the 25 commits on the project's main branch dated from 23 October, 15 are labelled as changes to the SSH package. On the self-hosted side, the headscale v0.29.6 release of 24 October deals with the eMudhra certificate issue and does not mention these findings.
What administrators can do now
The report's interim advice starts with access policy. Rewrite Tailscale SSH rules as per-pair grants, remove rules that cover a whole identity or tag, and never allow privileged target accounts. On Tailscale's hosted service, the forwarding flags in each rule can be set to denied. Headscale v0.29.5 offers no way to switch forwarding off, so the report says to "treat every headscale SSH grant as root-equivalent" until a fix ships.
Devices that do not need Tailscale SSH can have it turned off with tailscale set --ssh=false. Tailscale's documentation warns that administrators should make sure they have another way into the machine first, or they may lose access to it. The report also recommends node-key expiry on server fleets and, if a device is suspected of compromise, deleting it at the control plane, because a wiped machine leaves any copied keys valid until the device is deleted or they expire.