TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

Description: A single malformed HTTP request to a node running Tailscale Serve or Funnel could pin a CPU core indefinitely, causing denial of service. What happened? Tailscale Serve and Tailscale Funnel proxy incoming HTTP requests to local backends by matching the request path against the configured mount points.

When resolving the handler for a request, Tailscale walked the request path upward one directory at a time, expecting the walk to eventually terminate at the root path /. For requests whose path did not begin with /, this walk never reached / and never matched a mount point, causing the loop to spin forever. As the server enforced no request timeout, nothing interrupted the spin, and the goroutine held one core at 100% for the life of the process.

Tailscale now terminates the path walk for non-absolute paths, returning no handler and closing the request. This vulnerability is fixed in Tailscale version 1.98.

9 or newer. What was the impact? An attacker could send a crafted HTTP request to permanently consume one CPU core on the target node.

For Tailscale Serve, the request could originate from any peer on the tailnet with access to the node. For Tailscale Funnel, the request could originate from any unauthenticated host on the internet. Who was affected?

Nodes running Tailscale Serve or Tailscale Funnel on versions prior to 1.98.9.

What do I need to do? If you run Tailscale Serve or Tailscale Funnel, upgrade to Tailscale version 1.98.

9 or newer. Credits We would like to thank Anthropic and Ada Logics for reporting this issue. Description: Insecure command line argument handling in Tailscale SSH permitted root user access in violation of ACLs.

What happened? Tailscale SSH previously accepted usernames that contained a leading - character. On Linux platforms these usernames were passed as arguments to getent(1) to retrieve the corresponding passwd entry, where they were interpreted as flags permitting attacker-controlled behavior.

Specifically, if a user connected with the username -i this would have been interpreted as --no-idn and getent would have printed the entire passwd file contents starting with the root user, causing Tailscale to open an interactive root session. Tailscale SSH now rejects usernames with leading dashes. This vulnerability is fixed in Tailscale version 1.

98.9 or newer. What was the impact?

A user with SSH access to a Linux node would have been able to obtain a root session by connecting with the username -i, in violation of ACL policy. Who was affected? Users of Tailscale SSH on Linux hosts that rely on autogroup:nonroot user restrictions in Tailscale ACLs.

What do I need to do? If you use Tailscale SSH, upgrade to Tailscale version 1.98.

9 or newer. Credits We would like to thank Anthropic and Ada Logics for reporting this issue. Description: Insufficient inbound packet filtering in Services permitted access to loopback-bound listeners.

What happened? Tailscale Services are virtual tailnet destinations that can be hosted from one or more nodes on your tailnet. They allow you to manage networked resources such as databases separately from the nodes that back them.

In Tailscale versions prior to 1.98.9, nodes advertising services could accept inbound traffic to service IPs on ports that they did not advertise.

In these scenarios Tailscale would forward these packets to any process on the host loopback interface listening on the same port, allowing them to be accessed remotely. Tailscale now filters and rejects these packets with the appropriate TCP RST response when no corresponding handler exists for the service port. This vulnerability is fixed in Tailscale version 1.

98.9 or newer. What was the impact?

A user with ACL grants to a Tailscale Service could address it on non-advertised ports and reach processes listening on loopback on the node hosting the service. Who was affected? Users of Tailscale Services that rely on loopback-only network access restrictions on the nodes they use to host services.

What do I need to do? If you host Tailscale Services on nodes alongside processes bound to loopback, upgrade to Tailscale version 1.98.

9 or newer. Description: Tailscale SSH allowed users to be addressed by numeric UID, bypassing root user restrictions in ACLs. What happened?

Tailscale SSH previously allowed users to be addressed by their username or UID value, however the root user restrictions in ACL enforcement only considered the former. A user with non-root SSH access who addressed 0@host would have been able to access root in violation of ACLs. Tailscale now disallows the use of UIDs or numeric-only usernames via SSH to avoid this ambiguity.

This vulnerability is fixed in Tailscale version 1.98.9 or newer.

What was the impact? A user with SSH access to a node would have been able to SSH as root using the username 0 in violation of ACL policy. Who was affected?

Users of Tailscale SSH on Linux/Unix hosts that rely on autogroup:nonroot user restrictions in Tailscale ACLs. What d