Tailscale 1.104.7 Fixes Kubernetes API Proxy Impersonation

Tailscale has published security bulletin TS-2026-018 for a flaw in the Kubernetes operator’s API server proxy that allowed a host without a Tailscale identity to impersonate any node on a tailnet. The bulletin, dated 12 November 2026, says the issue is fixed in Tailscale version 1.104.7 or newer. It lists no CVE and does not mention any exploitation.

The new bulletin is separate from the Tailscale SSH flaws that TSN covered in late October, which Tailscale addressed in version 1.104.4 under bulletins TS-2026-014 to TS-2026-017. Those earlier issues concerned privilege escalation for someone already allowed to connect over Tailscale SSH. TS-2026-018 sits in a different component, on a different trust boundary, and in a later patch.

The Tailscale Kubernetes operator fallback only applied on a narrow path

The operator’s API server proxy is meant to authenticate requests from tailnet clients to a cluster’s Kubernetes API server. Tailscale says it resolves the caller’s Tailscale identity from the source address of the connection and forwards that identity to kube-apiserver using Kubernetes impersonation headers.

In deployments that run the proxy as a dedicated ProxyGroup with spec.type: kube-apiserver, or as a standalone k8s-proxy, the proxy fell back to the client-supplied X-Forwarded-For header when that source-address lookup failed. A host reached over a subnet route, but not enrolled in the tailnet, has no Tailscale identity, so the lookup always fails and the fallback applies. Such a host, Tailscale says, “could set X-Forwarded-For to any node’s Tailscale IP address and have its requests processed by kube-apiserver as that node.”

The impact is stated plainly: “A host on an advertised subnet with no Tailscale identity of its own could make requests to your Kubernetes API server as any tailnet node, including nodes with full cluster administrator access.”

The affected configuration is narrow. Tailscale says the bulletin applies only where that dedicated ProxyGroup or standalone k8s-proxy is in use, the proxy’s ProxyClass sets spec.tailscale.acceptRoutes to true, and an ACL grant allows connections from hosts behind subnet routes. “The operator’s in-process API server proxy is not affected.” Clients enrolled in the tailnet, it says, “authenticate through their real source addresses and cannot trigger this fallback.”

Version 1.104.7 stops the proxy trusting X-Forwarded-For

For operators who use the dedicated API server proxy, the advice is to update the deployment to Tailscale version 1.104.7 or newer. The 12 November changelog entry for Kubernetes Operator v1.104.7 states: “The Kubernetes API server proxy identifies a caller only by the connection’s source address, and no longer uses the X-Forwarded-For header.” The bulletin uses the same terms: Tailscale now identifies callers solely from the connection’s source address and no longer accepts X-Forwarded-For.

If hosts on the subnets could previously reach the proxy, Tailscale also tells operators to “review your Kubernetes audit logs for unexpected impersonated identities.” The company thanks Emilio Mendoza for reporting the issue.

The same-day client changelog also records an unrelated Go and TLS ClientHello change in Tailscale v1.104.7. That item is not the Kubernetes-operator fix.

Kubernetes clusters already treat identity as a first-class control, which is why a proxy that speaks impersonation headers sits in a sensitive place. Other TSN coverage this month has looked at that stack from different angles, including AWS Nitro Sandboxes for EKS pods and, in a different product, N-able’s advice to disable N-central’s Legacy API.

A stolen header is a different failure from Tailscale SSH

The October SSH bulletins were about what an already authorised peer could do once a session was open. This one is about who the API server believes is speaking. That is a narrower configuration, but not a smaller class of mistake. Kubernetes impersonation headers are a privileged way to act as another identity. A fallback that takes a client-supplied X-Forwarded-For value and treats it as a tailnet node is, in that setting, a way for a host that was never enrolled to borrow a name the cluster already trusts, including a name with full administrator rights.

Tailscale’s own bounds matter here. The in-process API server proxy is outside the affected path. Enrolled clients, it says, still authenticate from their real source addresses and cannot trigger the fallback. Those limits are why most tailnets will not meet the conditions in the bulletin. They are also why the operators who do meet them are being pointed at Kubernetes audit logs rather than at a general client update alone. An unexpected impersonated identity in those logs would be the practical test of whether the fallback was used, not a substitute for installing 1.104.7.

The absence of a CVE, and the silence on exploitation, should be read as gaps in the public record, not as a finding that nobody tried the path. The earlier SSH bulletins also listed no CVE. The useful next facts are whether operators who ran the dedicated proxy with acceptRoutes enabled report anything in their audit logs, and whether a CVE is later assigned to TS-2026-018. Until then, the bulletin and the changelog already give the same instruction: move the dedicated API server proxy to 1.104.7 or newer, and read the logs if subnet hosts could reach it.

Sources

• Tailscale, “Security Bulletins,” TS-2026-018, 12 November 2026
• Tailscale, “Changelog,” Kubernetes Operator v1.104.7, 12 November 2026

Related stories

• Tailscale Says Version 1.104.4 Fixes Its SSH Root-Access Flaws is the earlier, separate Tailscale SSH bulletin series, fixed in 1.104.4.
• AWS Launches Nitro Sandboxes for EKS Pods and Tasks
• N-able Says Disable N-central Legacy API and Check Servers