Tailworm: the Tailscale SSH root escalation, fixed

What was disclosed

On 25 October 2026, Cyberdione Labs published a report it called Tailworm: 11 findings against the Tailscale client (tested on version 1.104.2) and against headscale, the open-source control server (tested on 0.29.5). The report went public very shortly after it reached Tailscale, so for a few days the details were out before a patch. Tailscale published four security bulletins, TS-2026-014 to TS-2026-017, dated 26 October, and shipped the fixes in client 1.104.4 on 28 October. No CVE identifiers had been assigned at the time of writing.

Some of the report's other findings concern headscale itself, such as memory exhaustion on the control server. Headscale is a separate project: updating the Tailscale client does not fix a headscale server, so if you run one, follow the headscale project's own releases.

How the escalation works

Tailscale SSH is not OpenSSH. It is an SSH server built into tailscaled, the Tailscale daemon, which runs as root so it can open sessions as whichever user the tailnet policy allows. Like OpenSSH it supports forwarding, including Unix socket forwarding (ssh -L and ssh -R with a socket path), which joins a socket on one machine to the other end of the SSH connection.

The forwarding code checked the requested socket path by name against what the session's user was allowed to use, but the actual connect, bind and unlink were then carried out by the root daemon. According to the published analysis, a race between the check and the use could defeat that allowlist. The result: a session for an ordinary user could end up connected to sockets that only root is meant to open.

Several root-only sockets are, in practice, root itself:

• The Docker socket (/var/run/docker.sock): whoever can talk to the Docker daemon can start a container that mounts the host's root filesystem.
• The systemd and D-Bus sockets: they can create and restart services, and services run as root.
• The tailscaled local API socket: it controls the node's Tailscale configuration, SSH settings included.

In a lab, the researchers chained these steps from one host to the next, which is where the worm name comes from. As heise and others point out, this is lateral movement by an attacker who already has a foothold, not code that spreads by itself. No exploitation in the wild had been reported at the time of writing.

Who is affected, and who is not

• Affected: Linux and Unix nodes with Tailscale SSH turned on (tailscale set --ssh, or the SSH setting in the admin console), on a client older than 1.104.4, where the tailnet policy lets other devices SSH in with forwarding allowed.
• The precondition: the attacker needs a device that your policy already allows to SSH to the target, for example a developer laptop or a CI runner that was itself compromised. It escalates an authorised session; it does not let an unknown device in.
• Not affected by TS-2026-014: OpenSSH (sshd) that you simply reach over a Tailscale connection. There, Tailscale only carries the traffic; the SSH server is a separate program with its own rules.
• Not affected: nodes where Tailscale SSH is turned off.

Check your own hosts

Start with an inventory: which of your machines run Tailscale, and which of those have Tailscale SSH turned on. The admin console's Machines list shows an SSH badge on nodes that serve Tailscale SSH. Then, on each server:

# 1. Which client version? You want 1.104.4 or later.
$ tailscale version

# 2. Update from the Tailscale package repository
# RHEL, AlmaLinux, Rocky, Oracle Linux:
$ sudo dnf upgrade tailscale
# Debian, Ubuntu:
$ sudo apt-get update && sudo apt-get install --only-upgrade tailscale

# 3. Confirm the new version is the one running
$ tailscale version

If you cannot update today, close the door in another way, in this order of preference:

Harden beyond the patch

• Keep the client updating itself: tailscale set --auto-update, so the next fix lands without anyone having to remember.
• Treat SSH rules as privilege grants: the security of the source device is now part of the security of the target.
• Keep the Docker socket where it is needed: do not add ordinary users to the docker group; it is root by another name.
• Watch for the unexpected: new containers, new systemd units, or changed Tailscale settings on servers are worth an alert.
• Check the earlier fixes too: Tailscale 1.98.9 already closed related Tailscale SSH and Serve issues in June and July 2026, for example TS-2026-004 (symlinks that bypassed the socket path checks) and TS-2026-006 (numeric user IDs that bypassed root restrictions). A node still older than that is exposed to those as well.

Context: earlier Tailscale advisories

Tailscale keeps a public security bulletin page and has handled serious bugs before, for example CVE-2022-41924, a critical flaw in the Windows client fixed in 1.32.3, and CVE-2023-28436, where Tailscale SSH on FreeBSD ran commands with wider group permissions than the policy allowed, fixed in 1.38.2. The lesson is not to avoid Tailscale: fixes landed within days and the bulletins are clear. The lesson is to know where you run it, keep it current, and treat any SSH path through it as a privileged one.

Sources

• Tailscale security bulletins (TS-2026-004 to TS-2026-017)
• heise online: Tailscale SSH update patches "Tailworm" security flaws
• The Hacker News: Tailscale patches SSH flaws that could let hacked devices gain root access on other servers