Tailscale 1.104.4 fixes SSH and Serve flaws that reached root-only sockets

Tailscale 1.104.4 fixes SSH and Serve flaws that reached root-only sockets

26 October 2026: Tailscale has fixed four flaws in Tailscale SSH and Tailscale Serve, published as bulletins TS-2026-014 to TS-2026-017, in version 1.104.4. The worst let an authorised SSH peer reach root-only Unix sockets such as the Docker socket, and one Serve flaw allowed full takeover of a node through its local API.

Not yet independently verified. Tailscale's bulletins carry no CVE numbers, and its investigation page said more findings were still being reviewed. Press reports speak of almost a dozen flaws; Tailscale's bulletins list four, which is what we report. We will update this when it can be confirmed, and remove this note.

The fixed client was tagged on GitHub early on 28 October UTC. Details of the flaws had circulated before the fixes were ready; SecurityWeek describes an uncoordinated disclosure of what researchers called "Tailworm".

The four bulletins

Bulletin	Component	What it allowed	Who is exposed
TS-2026-014	Tailscale SSH	Peers with forwarding rights reach root-only sockets (Docker, tailscaled local API)	SSH enabled with local or remote forwarding allowed
TS-2026-015	Tailscale SSH	Memory exhaustion that kills tailscaled	Any node running Tailscale SSH, by an authenticated session
TS-2026-016	Tailscale Serve	Full node takeover via the local API; root dials of arbitrary sockets	Serve with Unix socket backends where local users can write config or backend paths
TS-2026-017	Tailscale Serve	Capability headers from one mount sent to another	Serve TLS with two or more mounts needing different capabilities

All four are fixed in 1.104.4 or newer.

How the SSH forwarding flaw worked

The SSH server runs inside the root-privileged tailscaled process. Tailscale says it checked Unix socket paths lexically but then performed the operations as root, which created three problems at once: privileged dials through local forwarding (ssh -L), replacement of root-owned sockets through remote forwarding (ssh -R), and a race in which the kernel re-resolved a path after the allowlist check. Together they removed the allowlist as a security boundary. The fix performs forwarding as the authenticated user instead of as root.

TS-2026-016 had a similar root cause in Serve: TCP forwards to Unix sockets dialled the target as root with no guard, so raw bytes could be passed into the local API socket, and a symlink check ran only when the configuration was reloaded rather than on each connection.

What to do before every node is updated

Update clients to 1.104.4. Where that takes time, Tailscale's own mitigation for the forwarding flaw is to set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service; this disables SSH forwarding without turning off Tailscale SSH.

In its investigation update of 26 October, Tailscale said most of the SSH findings were privilege escalation by someone already authorised to connect, and that it was not recommending everyone disable Tailscale SSH. It advised reviewing SSH access policies so that only the users and devices that need access have it. A node that exposes the Docker socket to anyone with SSH forwarding rights should be treated as having given those users root.

Company profile on TrustList: Tailscale

Sources

• Tailscale: Security bulletins TS-2026-014 to TS-2026-017, 26 October 2026
• Tailscale: Tailscale SSH investigation update, 26 October 2026
• Tailscale on GitHub: release v1.104.4, 28 October 2026
• SecurityWeek: Tailscale rushes patches after uncoordinated disclosure of Tailworm flaws, 27 October 2026