GHSA-g936-7jqj-mwv8: Administrative Token Leakage and Privilege Escalation in TSDProxy

TSDProxy is an open-source Tailscale reverse proxy designed to automate the process of exposing Docker containers and internal host services directly to a Tailnet. When routing traffic to these upstream backends, TSDProxy can be configured to forward identity details using HTTP request headers, such as user IDs and usernames, allowing backend services to verify user identity seamlessly.

To facilitate internal administrative operations like starting, stopping, or pausing individual proxy definitions, TSDProxy maintains an internal HTTP management API. This management plane is designed to run locally, typically binding to the loopback interface on port 8080. It utilizes an internal per-process authentication token to validate administrative commands originating from the local machine.

The vulnerability arises because TSDProxy leaks this highly sensitive internal administrative token to untrusted third-party upstream backends. Under default configurations where identity headers are enabled, every proxied HTTP request carries the token to the backend server. This flaw creates a vector where any compromised or malicious upstream backend can capture the token and escalate privileges to fully control the TSDProxy instance.

The root cause of this vulnerability lies in the combination of unconditional token injection and improper context checking within the reverse proxy implementation. In the file internal/proxymanager/port.go, the handler loops through incoming requests and appends identity-related headers. If the identityHeaders boolean is enabled, the proxy attempts to extract user identity information from the request context.

The application implements a middleware called ProviderUserMiddleware which is intended to populate the request context using Tailscale's Whois utility. However, for unauthenticated requests, such as public traffic coming through a Tailscale Funnel, the middleware still inserts a zero-value Whois{} struct into the context. Consequently, calling WhoisFromContext returns a success status (ok=true) because a Whois structure exists in the context, even though the fields within that structure are completely empty.

Due to this flaw, the execution block responsible for header injection is entered for all incoming HTTP requests. Within this block, the code sets the x-tsdproxy-auth-token header using the value retrieved from core.ProxyAuthToken(). This action unconditionally appends the secret administrative token to outgoing requests destined for proxied backend applications, irrespective of whether the original requester is an administrator, a standard user, or an unauthenticated anonymous visitor.

In the vulnerable version of internal/proxymanager/port.go, the header injection logic fails to validate the destination of the proxied request or the authenticity of the user. The following code segment illustrates this flaw:

// Vulnerable Code Path
if identityHeaders {
    if user, ok := model.WhoisFromContext(r.In.Context()); ok {
        // The ok boolean evaluates to true even for anonymous requests
        // The internal administrative token is sent to the upstream backend unconditionally
        r.Out.Header.Set(consts.HeaderAuthToken, core.ProxyAuthToken())
    }
}

The official patch applied in commit 434819b4421e6b7471eaeb307533f19c52c222d8 implements stringent checks to remediate the vulnerability. First, it requires the user identifier to be non-empty, preventing anonymous context entries from triggering header injection. Second, it restricts token forwarding strictly to cases where the proxy target is identified as the local management interface:

// Patched Code Path
if identityHeaders {
    if user, ok := model.WhoisFromContext(r.In.Context()); ok && user.ID != "" {
        r.Out.Header.Set(consts.HeaderID, user.ID)
        r.Out.Header.Set(consts.HeaderUsername, user.Username)
 
        // Forward the auth token only to the internal management
        // server (self-proxy case). Never expose it to external
        // backends — a leaked token allows identity spoofing on
        // the management API.
        if isManagementTarget(pconfig.GetFirstTarget()) {
            r.Out.Header.Set(consts.HeaderAuthToken, core.ProxyAuthToken())
        }
    }
}

Additionally, the patch introduces the helper function isManagementTarget to parse the destination URL and verify if it represents a loopback host on the designated HTTP management port. This stops the administrative token from being exposed to any backend container or external host service, while maintaining the self-proxying functionality required for legitimate management operations.

Exploitation of GHSA-g936-7jqj-mwv8 depends on the attacker's ability to monitor HTTP requests on an upstream backend service proxied by TSDProxy. This condition is easily met if the attacker compromises an existing container, deploys an unauthorized application, or controls a legitimate backend service. Once a single request passes through the proxy, the backend application receives the x-tsdproxy-auth-token header, exposing the administrative credential.

After harvesting the token, the attacker must be capable of reaching the local management port of TSDProxy, which typically binds to 127.0.0.1:8080. This access is possible if the backend container runs with host networking privileges (--network=host), if both services share a network namespace, or if the attacker has local shell access on the host operating system. The attacker can then issue administrative requests to the loopback interface, supplying the stolen token and a spoofed identity.

By transmitting a request to /api/v1/proxies accompanied by the hijacked token, the attacker bypasses all access controls. The management API trusts the caller implicitly due to the matching token and the loopback origin, giving the attacker structural authority over the reverse proxy configuration.

The security impact of this vulnerability is critical, as it allows a complete compromise of the reverse proxy engine's management plane. Armed with the stolen administrative token, an attacker can modify proxy definitions, stop existing proxies, start new services, and alter configuration files. This level of access grants the attacker control over the routing of traffic within the Tailnet environment.

Furthermore, the management API exposes detailed configuration structures that reveal internal network topologies, container identifiers, and backend URLs. An attacker can leverage this information to map out isolated systems, locate other sensitive databases, and plan further lateral movement. Additionally, administrative capabilities such as triggering server-side webhooks present opportunities for server-side request forgery (SSRF) and localized denial of service.

The CVSS v3.1 base score is calculated at 8.3, reflecting high confidentiality, integrity, and availability impacts. While the exploitation requires the attacker to occupy a position within the internal network or a proxied backend, the resulting scope change makes the vulnerability particularly significant because a compromise of a standard container escalates directly to host-level network proxy control.

The primary remediation strategy is upgrading TSDProxy to a version containing the official fix. The vulnerability is resolved in the Go pseudo-version 1.4.4-0.20260603142855-434819b4421e, which implements the patched header sanitization and the target validation checks. Organizations running TSDProxy via Docker should pull the latest image built from the main branch containing the patched proxy manager code.

In environments where immediate software upgrades are not feasible, network-level mitigations must be deployed to disrupt the exploitation path. Security teams should enforce strict network namespace isolation, ensuring that upstream backend containers are placed in isolated bridge networks rather than using host networking mode. This prevents backend applications from accessing the host loopback interface where the management API resides.

Additionally, administrators can mitigate the risk by setting identityHeaders: false in the proxy configuration file. This completely disables the forwarding of Tailscale user attributes to the backends, thereby preventing the execution block from injecting the administrative token. Finally, host firewalls should be configured to drop any traffic attempting to reach port 8080 from non-trusted interfaces or container bridge subnets.