Tailscale v1.104.4 Fixes Tailworm SSH Forwarding and Serve Socket Flaws

The Four Bulletins, Their Impact and Who Is Affected #

Each bulletin states that the flaw is fixed in Tailscale 1.104.4 or newer, and each names its own conditions. They differ more than the shared fix version suggests.

TS-2026-014: SSH Forwarding Ran as Root #

The SSH server inside the root-privileged tailscaled checked Unix socket paths by their text but then performed the socket operations as root. The bulletin lists three resulting flaws: local forwarding with ssh -L could dial privileged sockets, remote forwarding with ssh -R could replace sockets by unlinking root-owned ones, and a race defeated the path allowlist because the kernel resolves the path again after the check. Together they removed the allowlist as a security boundary. The v1.104.4 changelog says forwarding now runs on behalf of the authenticated user rather than as root.

For nodes that cannot update at once, the bulletin gives a mitigation: set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service, which turns off forwarding without turning off Tailscale SSH.

TS-2026-015 and the Two Serve Flaws #

In TS-2026-015, continuous window-change messages and appended environment variables made tailscaled allocate memory without limit, and the memory stayed allocated after the peer disconnected. v1.104.4 bounds that memory and releases it on disconnect.

TS-2026-016 has two parts. TCP forwards to Unix socket backends had no guard and dialed the target as root, which let raw bytes reach the local API socket with the daemon's own permissions. The symlink guard for HTTP proxies ran only when the configuration was reloaded, so a backend path could be swapped for a symlink afterwards. v1.104.4 restricts TCP forwards to Unix socket backends and checks the backend path on every connection.

TS-2026-017 is a race in Serve over HTTP/2: all streams on one TLS connection shared one context, so Tailscale-App-Capabilities values for one mount could be sent with a request to another. An application that authorizes peers by that header could then answer a peer it should have refused.

What the Tailworm Report Did Not Show #

Tailscale's findings post, written by Mike Shaver, states that the SSH flaws do not let an unauthenticated attacker connect to arbitrary Tailscale SSH servers. An attacker needs a foothold on an authorized peer, SSH access granted in the tailnet policy file and the conditions each flaw requires, and could reach only machines that policy already allowed. Tailscale therefore describes the scenario as lateral movement within policy, not a self-replicating worm.

The report also listed five Serve and Funnel findings. Three were bugs fixed in v1.104.4; Tailscale treats the other two as intended behavior, since bypassing the Funnel attribute check requires local admin access and TS_SERVE_ALLOW_ALL_INTERFACES is an opt-in setting. A vulnerability in Conn25, the next generation of app connectors, concerns a feature that has not been released; the current app connectors are not affected. Tailscale says it received the report on October 24, two hours before the researcher published it, and released the fixes four days later.

Updating Tailscale and Narrowing SSH Access #

1. Update every node that runs Tailscale SSH or Tailscale Serve to v1.104.4 or a later 1.104 release. v1.104.5 on November 2 also fixes SSH sessions that disconnected when a check mode approval expired and SSH restarts that could hang.
2. On Windows, install new nodes with the v1.104.5 or later .exe installer, which fixes a privilege escalation at install time; existing installations do not need to be reinstalled.
3. Until a node is updated, set TS_SSH_DISABLE_FORWARDING=1 for tailscaled and restart it, and remove forwarding from SSH rules that do not need it.
4. On nodes with Serve Unix socket backends, check who can write the Serve configuration and the backend paths, and restrict both to administrators.
5. Review the SSH section of the tailnet policy file so access is limited to the users and devices that need it, and use check mode for sensitive systems, as the findings post recommends.

Checking a Node: Version, Serve Backends and SSH Forwarding #

The version shows whether the node has the fixes. The Serve status lists the backends, including Unix sockets, and the environment check shows whether the forwarding mitigation is set on a systemd host.

tailscale version
tailscale serve status
systemctl show tailscaled --property=Environment
grep -n "TS_SSH_DISABLE_FORWARDING" /etc/default/tailscaled