TSDProxy Authentication Token Disclosure Enables Management API Bypass
TSDProxy forwards its internal management authentication token to all proxied backend services by default, allowing network-local backends to bypass Tailscale identity verification and escalate privileges via the management API.
Affected
Vulnerability Analysis
Root Cause & Class: TSDProxy suffers from an authentication context leakage vulnerability where sensitive per-process authentication tokens are forwarded unconditionally to upstream backend services via the x-tsdproxy-auth-token HTTP header. The vulnerability stems from two design flaws: (1) ProviderUserMiddleware invokes WhoisNewContext for all requests regardless of authentication state, and (2) the ReverseProxy.Rewrite function returns ok=true even for zero-value Whois{} structs (unauthenticated/Funnel requests). This token is the same secret trusted by the management HTTP server (127.0.0.1:8080) to validate forwarded Tailscale identity claims, creating a critical privilege escalation path.
Proof-of-Concept Significance: The PoC demonstrates that any backend service receiving proxied traffic can extract and replay the forwarded token to the localhost management port with a crafted x-tsdproxy-id header, completely bypassing Tailscale's identity verification layer. This is reliable and deterministic; it requires only network-layer access between the backend and TSDProxy (same host, Docker host-network mode, or shared network namespace). The preconditions are common in containerized deployments, making real-world exploitation feasible for malicious or compromised backends.
Detection Guidance: Monitor for:
- HTTP requests to
127.0.0.1:8080or management port originating from backend service processes x-tsdproxy-auth-tokenheaders in access logs (should never appear in inter-service traffic)x-tsdproxy-idheaders with values not matching the actual requesting identity- Rapid authentication attempts to management endpoints from unexpected sources
- Log patterns showing successful authentication followed by unauthorized API calls (management escalation)
- Network traffic analyzer rules detecting token replay patterns or management port access from container/host boundary
Mitigation Steps: (1) Patch immediately to the latest TSDProxy version that disables token forwarding to untrusted backends or implements per-backend token scoping. (2) Configuration hardening: disable identityHeaders if not required by backend services. (3) Network isolation: restrict backend-to-management port connectivity using firewall rules or network policies; backends should never reach 127.0.0.1:8080. (4) Architecture review: audit deployment topology to eliminate shared network namespaces between TSDProxy and untrusted backends. (5) Token rotation: immediately rotate management authentication secrets post-patch. (6) Temporary workaround: run TSDProxy in separate network namespace from backends if patching is delayed.
Risk Assessment: Exploitation likelihood is high in containerized environments (Kubernetes, Docker Compose) where network isolation is weak. Threat actor interest is significant: this enables silent lateral movement from compromised backend services to full cluster/management privileges without alerting identity systems. The attack is stealthy, deterministic, and requires minimal sophistication once network access is established. This represents a critical trust boundary violation in multi-tenant or defense-in-depth architectures.
Sources