VULNpocalypse
HighVulnerabilityPatch available

Tailscale SSH and Serve flaws (TS-2026-014 to TS-2026-017) let a permitted session reach root-only sockets

Tailscale SSH forwarding and Serve Unix-socket backends ran as root, so an allowed session could take over a node. Update every node to Tailscale 1.104.4.

Published
Updated
Fixed in
Tailscale 1.104.4; libtailscale 0.2.0 (TS-2026-012); Tailscale 1.104.2 (TS-2026-013)
Exploitation
No. Neither Tailscale nor the researcher reports use in attacks; the proof of concept went only to Tailscale

What happened

On 26 October 2026, Tailscale published four security bulletins with no CVE IDs or severity scores (Tailscale):

  • TS-2026-014. The Tailscale SSH server checked Unix socket paths by their text, but did the forwarding as root. A session with local forwarding could dial root-only sockets, remote forwarding could replace sockets, and a race defeated the path allowlist. It affects nodes with Tailscale SSH whose access policy allows local or remote forwarding.
  • TS-2026-015. Repeated window-change messages and environment variable appends made tailscaled memory grow without limit, and the memory stayed after the peer left. It needs an authenticated session the policy permits.
  • TS-2026-016. tailscale serve TCP forwards to Unix sockets had no guard and dialed as root, so they could reach the tailscaled local API socket. A symlink check for HTTP proxies ran only at config reload, so a backend path could be swapped for a symlink later. It affects nodes where a local operator can write Serve configs, or local users can write to the backend paths.
  • TS-2026-017. Concurrent HTTP/2 streams on one connection shared a context, so Tailscale-App-Capabilities values from one Serve mount could apply to another. It affects nodes with Serve TLS and at least two mounts with different capability requirements.

The Hacker News describes the practical effect: a permitted session could reach sockets such as the Docker socket or the tailscaled local API, and the Serve flaw gives remote control of the node (The Hacker News).

Tailscale 1.104.4, released on 28 October, fixes all four. SSH Unix socket forwarding now runs as the authenticated user, SSH session memory is bounded, Serve restricts TCP forwards to Unix sockets and rechecks backend paths on each connection, and capabilities come from each request’s own context. Version 1.104.3 was internal only (Tailscale changelog).

How it came out. Erica Windisch of Cyberdione Labs published the findings as “Tailworm”: 11 findings against Tailscale 1.104.2 and headscale 0.29.5, six rated high, four of those in Tailscale SSH (SecurityWeek). Tailscale got the report on Saturday 24 October, about two hours before it went public. Windisch called the chain wormable. Tailscale rejected that label and described it as lateral movement limited to connections the policy already allows (The Hacker News). Tailscale says this “is not the same as an unauthenticated attacker being able to connect to arbitrary machines” (SecurityWeek).

What an attacker needs. Control of a device that your access rules allow to open an SSH session to the target, with forwarding permitted. The proof of concept is not public (The Hacker News).

Two other October bulletins. TS-2026-012 (13 October) is a file-descriptor mix-up in libtailscale, the embedding library, fixed in libtailscale 0.2.0. TS-2026-013 (21 October) covers eight compromised eMudhra TLS intermediate certificates; Tailscale 1.104.2 distrusts them (Tailscale).

Am I affected?

Any node older than 1.104.4 is affected if it runs the Tailscale SSH server, or serves Unix socket backends. The SSH server runs only on Linux and the open-source macOS build (The Hacker News).

bash
# Version on this node
tailscale version

# Is this node running the Tailscale SSH server?
tailscale debug prefs | grep -i '"RunSSH"'

# What is this node serving? Look for backends that point at a Unix socket path
tailscale serve status

Then check your tailnet policy file. Any ssh rule is a path to TS-2026-014 and TS-2026-015 on the destination nodes, so list which sources can reach which servers. Pay most attention to servers that run Docker or hold other root-only sockets.

What to do now

  1. Upgrade every node to Tailscale 1.104.4 or later. That includes servers, CI runners and containers that run tailscaled, not just laptops (Tailscale changelog).
  2. If you cannot upgrade a node yet, turn off SSH forwarding. Set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart. Tailscale SSH keeps working without forwarding (Tailscale). On Linux packages, tailscaled reads its environment from /etc/default/tailscaled:
bash
echo 'TS_SSH_DISABLE_FORWARDING=1' | sudo tee -a /etc/default/tailscaled
sudo systemctl restart tailscaled
  1. Cut SSH rules down. Tailscale recommends limiting SSH access to the users and devices that need it, and tightening access to sensitive systems for now (Tailscale). SSH check mode does not help, because it guards only the start of a session, not forwarding inside it (The Hacker News).
  2. Remove Serve configs that point at Unix sockets on nodes you cannot upgrade, and make sure only root can write the backend paths. TS-2026-015, TS-2026-016 and TS-2026-017 have no workaround other than upgrading (Tailscale).
  3. Rebuild apps that embed libtailscale (TailscaleKit, the Ruby gem, the Python package) against 0.2.0. If you made access decisions from tailscale_getremoteaddr, review those logs (Tailscale).
  4. If you think a node was abused, delete it in the admin console. The Hacker News notes a stolen device key stays valid until the device is removed at the control plane; reimaging alone does not revoke it (The Hacker News).

Sources