Jul 13, 2026
TS-2026-008
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.
TS-2026-009
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.