Tailscale v1.104.4: Fixes SSH Root‑Socket Forwarding, Serve Flaws

Tailscale SSH forwarding to root-only Unix sockets (TS-2026-014) #

SSH servers need elevated privileges to start sessions as other Unix users, and the findings post describes the challenge as keeping those privileges out of the connected user's session, including SSH forwarding. Under the affected behaviour, authorized peers could use local and remote forwarding to reach root-only Unix sockets such as the Docker socket or the tailscaled local API. The fix makes Tailscale SSH perform Unix socket forwarding on behalf of the authenticated user rather than as root, according to the v1.104.4 changelog.

This suggests that a forwarding setup which relied on root to reach a local socket will behave differently after the upgrade, and that the connected user's own permissions now decide what is reachable. Anyone who uses forwarding to reach the Docker socket or the local API should test that path after updating.

The report's "Tailworm" name prompted questions about whether this is a computer worm. The findings post says the vulnerabilities do not describe self-replicating malware. It describes lateral movement limited to SSH connections that the tailnet policy file already allows, so an attacker could reach only the machines that file permits.

Tailscale SSH memory growth in tailscaled (TS-2026-015) #

Continuous window-change messages and environment variable appends could make tailscaled's memory use grow without bound. The changelog lists the result as denial of service through unbounded memory growth in tailscaled. The fix bounds the memory used for session handling and releases it when the peer disconnects. Because the change sits in Tailscale SSH session handling, the upgrade is what closes it on nodes that run Tailscale SSH.

Tailscale Serve TCP forwards to Unix socket backends (TS-2026-016) #

Serve could forward TCP traffic to Unix socket backends in a way that reached privileged sockets, including the tailscaled local API socket. The v1.104.4 changelog says Serve now restricts TCP forwards to Unix socket backends and revalidates backend paths on each connection. This suggests that a backend path is checked again for every connection, not only when Serve is configured.

Tailscale Serve with TLS and HTTP/2 capability headers (TS-2026-017) #

TS-2026-017 Description: HTTP/2 shared serve context could send the wrong Tailscale-App-Capabilities values across mounts.

With Serve TLS enabled, the server advertises HTTP/2, and all streams on one connection shared a single serveHTTPContext. A race condition let capabilities written per request by the handler reach the reverse proxy's shared hook, so capabilities from one mount could bleed into requests for another. Applications that inspect Tailscale-App-Capabilities to authorize a peer might have made incorrect decisions, and a peer holding a capability for one mount could receive privileged responses from a mount it is not authorized to access.

The bulletin says the issue affects nodes with TLS enabled and at least two mounts with different capability requirements on the same node, and that it requires concurrent streams multiplexed on a single connection. The fix derives request capabilities from a per-request context instead of state shared across all streams.

Serve and Funnel findings that work as designed #

The findings post describes five Serve and Funnel findings. Three were bugs, and v1.104.4 fixes them. The other two describe intended behaviour: bypassing the Funnel attribute check requires local admin access, and TS_SERVE_ALLOW_ALL_INTERFACES is an opt-in setting meant to expose Serve beyond the tailnet. Because the post classes these two as designed behaviour, this suggests that upgrading does not change them, and their exposure depends on how the node is administered.

Conn25 app connectors are not affected in stable releases #

The report also identified a vulnerability in Conn25, the next generation of app connectors. The findings post says Conn25 is still in pre-production, has not been released, and that Tailscale was already aware of this issue. The stable app connectors available today are not affected.

Tailscale SSH report and response timeline #

Concerns about Tailscale SSH began circulating on social media on Friday, October 23. Tailscale received the researcher's report on the morning of Saturday, October 24, and the researcher published it two hours later. On Monday, October 26, Tailscale published an investigation update with its initial assessment and recommended precautions. The fixes shipped in v1.104.4, whose changelog is dated October 28, 2026.

Affected and fixed Tailscale SSH and Serve versions #

v1.104.4; TS-2026-017 needs v1.104.4 or newer. The sources do not list affected version ranges, so the table gives the fixed versions and the exposure conditions as each source states them. The changelog notes that v1.104.3 was an internal-only release.

Protection steps for Tailscale SSH and Serve nodes #

Start by updating to Tailscale v1.104.4 or newer, since the post recommends updating for Tailscale SSH users and TS-2026-017 requires it for TLS-enabled Serve.

1. Update each node that runs Tailscale SSH to Tailscale v1.104.4 or later.
2. Update each node that runs Tailscale Serve with TLS enabled to v1.104.4 or newer.
3. Review your Tailscale SSH policies so that access is limited to the users and devices that need it.
4. Consider SSH check mode for sensitive systems, which requires an additional authentication check before granting access.

How to check Tailscale SSH and Serve exposure on your tailnet #

Start with the tailnet policy file. A peer can reach the affected SSH paths only where SSH access is explicitly permitted in the tailnet policy file, so list the users and devices that have it. For each sensitive system, check whether SSH check mode is in place, since the findings post recommends it for those systems.

For Serve, check whether TLS is enabled on the node and whether the node has at least two mounts with different capability requirements, because TS-2026-017 depends on that combination. Then confirm that the installed Tailscale version is v1.104.4 or newer on every node that runs Tailscale SSH or Serve with TLS.