Security Bulletins · Tailscale

TS-2026-008Description: 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. TS-2026-009Description: 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. TS-2026-007Description: 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.

TS-2026-006Description: 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 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 Tim Hoffman (GM) for reporting this issue. TS-2026-005Description: Tailscale Serve Unix socket proxy targets were not restricted to root, allowing a non-root operator to proxy privileged sockets. What happened? Tailscale Serve can proxy incoming connections to local backends, including Unix domain sockets configured as proxy targets (for example, proxy: unix:/var/run/docker.sock). A non-root local user configured as the Tailscale operator can write Serve configuration through the LocalAPI. Tailscale restricts the ability to specify filesystem paths as Serve targets to the root user to prevent privilege escalations, however this check did not cover Unix socket proxy targets. A non-root operator could therefore have the tailscaled process running as root proxy to a privileged Unix socket, bypassing the filesystem permissions that would otherwise deny them access. Tailscale now restricts Unix socket proxy targets to the root user, matching the requirement already applied to filesystem handlers. This vulnerability is fixed in Tailscale version 1.98.9 or newer. What was the impact? A non-root user configured as the Tailscale operator could cause the tailscaled process running as root to connect to privileged Unix sockets they could not otherwise access.

Who was affected? Linux/Unix hosts running Tailscale Serve where a non-root local user was configured as the Tailscale operator and privileged Unix sockets (such as Docker, containerd, or CRI sockets) were present. What do I need to do? If you use Tailscale Serve, upgrade to Tailscale version 1.98.9 or newer. Credits We would like to thank Tim Sageser (dtrsecurity) for reporting this issue. TS-2026-004Description: Tailscale SSH Unix socket forwarding did not respect symlink permissions, allowing privileged socket access. What happened? Tailscale SSH includes the ability to forward both TCP and Unix sockets between the client and host. A bug in the filesystem permission checks within Tailscale SSH's Unix socket forwarding permitted an unprivileged user to bind and access a privileged socket on the remote host. Previously, when Tailscale SSH evaluated filesystem permissions for requested sockets, it only performed lexical matching of the requested path against its allowlists and denylists. An attacker who created a symlink at a path they owned (e.g., /home/$USER/my.sock) that pointed to a protected resource (e.g., /var/run/docker.sock) would have been able to bind and access the latter path in an SSH connection. This is possible because Tailscale runs as root and so has access to the privileged destination. In addition to lexical matching, Tailscale SSH now checks the requested and configured paths for symlinks and evaluates them to ensure that their destinations are also authorized. Symlinks with destinations outside of the configured allowlist will be denied. This vulnerability is fixed in Tailscale version 1.98.9 or newer. What was the impact? An unprivileged user would have been able to access privileged Unix sockets on the remote host. Who was affected? Users of Tailscale SSH on shared Linux/Unix hosts that rely on filesystem permissions to restrict access to Unix sockets. 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 Tim Sageser (dtrsecurity) for reporting this issue. TS-2026-003Description: OAuth access tokens recorded in tailnet audit logs.

What happened? The Tailscale coordination server emits an audit log recording all changes to a tailnet's configuration including the creation and management of access credentials. A bug in the Tailscale coordination server caused it to record the complete OAuth client access tokens within the audit log entries that describe their creation. This made the OAuth access tokens accessible to other tailnet actors who had access to the logs. What was the impact? A tailnet admin with access to audit logs would have been able to retrieve OAuth access tokens from the logs and use them to make authorized requests to the Tailscale API within the token's one hour validity window. Who was affected? All tailnets that used OAuth Clients to create access tokens from March 1st, 2026 to May 29th, 2026 are impacted. What do I need to do? There is no action necessary on the part of customers. New access tokens are now recorded in a redacted form in the audit log. Access tokens are created with a maximum valid lifetime of one hour so all historical tokens have already expired. Credits We would like to thank Conor Power (Snapchat) for reporting this issue. TS-2026-002Description: ACL capability bypass in the Tailscale client's web interface What happened? The Tailscale client runs a local web interface to manage its settings. This web interface can optionally be opened to other tailnet peers, for example to manage a tagged node on a headless host without SSH access. By default the interface is read-only, but tailnet admins can grant permissions to change certain settings using ACL grants. The /api/routes endpoint on the web interface allows changing the active exit node and advertised subnet routes. These settings are gated behind exitNodes and subnets grants respectively. There was a bug in the handler that reset both settings to their empty state if the request body was empty, even if the caller doesn't have either grant to allow that. This vulnerability is fixed in Tailscale version 1.98.0 and newer. What was the impact? A malicious tailnet node could disable the exit node and clear advertised subnet routes on other tailnet nodes that run the web interface. The malicious user would need to perform a login check and be granted access to port 5252 on the target node via tailnet ACLs.