TSDProxy: Internal proxy auth token forwarded to backend services enables management API escalation
## Description A vulnerability was discovered in TSDProxy where it forwards its internal per-process authentication token to all proxied backend services. When `identityHeaders` is enabled (the default), tsdproxy injects `x-tsdproxy-auth-token` into every upstream HTTP request alongside user identity headers. This token is the same secret used by the management HTTP server to trust forwarded Tailscale identity claims. A backend that receives this token can replay it from localhost to the management port with an arbitrary `x-tsdproxy-id` value, bypassing Tailscale authentication entirely. The token is forwarded unconditionally: `ProviderUserMiddleware` always calls `WhoisNewContext` regardless of whether the user is authenticated. In the `ReverseProxy.Rewrite` function, `WhoisFromContext` returns `ok=true` even for zero-value `Whois{}` (unauthenticated or Funnel requests). The `HeaderAuthToken` is set for every request when `identityHeaders=true`. The attack requires the backend to reach `127.0.0.1:8080`. This holds in: (1) non-Docker deployments where tsdproxy and a backend run on the same host, (2) Docker host-network-mode containers, (3) containers sharing tsdproxy's network namespace. ## Affected files - `internal/proxymanager/port.go:123-132` - `internal/core/admin.go:160-182` ```go // port.go: auth token forwarded regardless of user authentication state if identityHeaders { if user, ok := model.WhoisFromContext(r.In.Context()); ok { // ok=true even for empty Whois{} stored by ProviderUserMiddleware r.Out.Header.Set(consts.HeaderAuthToken, core.ProxyAuthToken()) // token sent to backend } } // admin.go: management port trusts x-tsdproxy-id from localhost when token is valid func ResolveWhois(r *http.Request) model.Whois { if IsLocalhost(r.RemoteAddr) { return model.Whois{ ID: r.Header.Get(consts.HeaderID), // attacker-controlled after stealing token } } return model.Whois{} } ``` ## Steps to reproduce 1. Deploy tsdproxy on a host (non-Docker) with a backend at `http://localhost:3000`. 2. Make a request through the Tailscale proxy. The backend receives `x-tsdproxy-auth-token` in the request headers. 3. From the host, replay the token to the management API: ```bash # Capture token from backend headers (e.g., via a header-reflection endpoint) TOKEN=$(curl -s http://localhost:3000/debug/headers | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['headers'].get('X-Tsdproxy-Auth-Token',''))") # Replay from localhost to gain admin access curl -H "x-tsdproxy-auth-token: $TOKEN" \ -H "x-tsdproxy-id: attacker" \ http://127.0.0.1:8080/api/v1/proxies # Returns full proxy list with admin access ``` ## Fix Remove `HeaderAuthToken` from the outgoing backend request, and guard identity-header injection on `user.ID != ""`: ```go // port.go: only inject headers for actually authenticated users if identityHeaders { if user, ok := model.WhoisFromContext(r.In.Context()); ok && user.ID != "" { r.Out.Header.Set(consts.HeaderID, user.ID) // HeaderAuthToken should NOT be forwarded to backends } } ``` ## Impact An attacker with code execution in any backend proxied by tsdproxy (on the same host) gains full management API control: restart or pause all proxied services (DoS), enumerate all proxy configurations and backend network topology, and trigger webhook deliveries (SSRF via configured webhook URLs). ## Credits Reported by Vishal Shukla (@shukla304 / @therawdev). ## Sponsorship This audit is from an AI-assisted research agent at [sechub.dev](https://sechub.dev). Running it on OSS projects is free for maintainers.
AI Analysis
Technical Summary
The vulnerability in TSDProxy arises because it forwards its internal authentication token (x-tsdproxy-auth-token) to all proxied backend services unconditionally when identityHeaders is enabled. This token is the secret used by the management HTTP server to trust forwarded identity claims. Since the token is forwarded regardless of user authentication state, a backend service that receives this token can replay it from localhost to the management API port (127.0.0.1:8080) with an arbitrary x-tsdproxy-id header, effectively bypassing Tailscale authentication. This enables an attacker with code execution in any backend on the same host to escalate privileges to full management API control. The vulnerability affects setups where the backend can access the management API via localhost, including non-Docker deployments and certain container network configurations. The recommended fix is to stop forwarding the auth token to backend services and only inject identity headers for authenticated users (user.ID != "").
Potential Impact
An attacker with code execution in any backend proxied by TSDProxy on the same host can gain full management API control. This includes the ability to restart or pause all proxied services, causing denial of service; enumerate all proxy configurations and backend network topology; and trigger webhook deliveries, potentially enabling server-side request forgery (SSRF) via configured webhook URLs. The vulnerability allows bypassing Tailscale authentication entirely by replaying the internal auth token from localhost.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix involves removing the x-tsdproxy-auth-token header from outgoing backend requests and only injecting identity headers for authenticated users (user.ID != ""). Until an official fix is available, avoid configurations where backend services can access the management API via localhost (127.0.0.1:8080), such as running backend and tsdproxy on the same host or using Docker host network mode. Monitor vendor advisories for an official patch or update.
TSDProxy: Internal proxy auth token forwarded to backend services enables management API escalation
Description
## Description A vulnerability was discovered in TSDProxy where it forwards its internal per-process authentication token to all proxied backend services. When `identityHeaders` is enabled (the default), tsdproxy injects `x-tsdproxy-auth-token` into every upstream HTTP request alongside user identity headers. This token is the same secret used by the management HTTP server to trust forwarded Tailscale identity claims. A backend that receives this token can replay it from localhost to the management port with an arbitrary `x-tsdproxy-id` value, bypassing Tailscale authentication entirely. The token is forwarded unconditionally: `ProviderUserMiddleware` always calls `WhoisNewContext` regardless of whether the user is authenticated. In the `ReverseProxy.Rewrite` function, `WhoisFromContext` returns `ok=true` even for zero-value `Whois{}` (unauthenticated or Funnel requests). The `HeaderAuthToken` is set for every request when `identityHeaders=true`. The attack requires the backend to reach `127.0.0.1:8080`. This holds in: (1) non-Docker deployments where tsdproxy and a backend run on the same host, (2) Docker host-network-mode containers, (3) containers sharing tsdproxy's network namespace. ## Affected files - `internal/proxymanager/port.go:123-132` - `internal/core/admin.go:160-182` ```go // port.go: auth token forwarded regardless of user authentication state if identityHeaders { if user, ok := model.WhoisFromContext(r.In.Context()); ok { // ok=true even for empty Whois{} stored by ProviderUserMiddleware r.Out.Header.Set(consts.HeaderAuthToken, core.ProxyAuthToken()) // token sent to backend } } // admin.go: management port trusts x-tsdproxy-id from localhost when token is valid func ResolveWhois(r *http.Request) model.Whois { if IsLocalhost(r.RemoteAddr) { return model.Whois{ ID: r.Header.Get(consts.HeaderID), // attacker-controlled after stealing token } } return model.Whois{} } ``` ## Steps to reproduce 1. Deploy tsdproxy on a host (non-Docker) with a backend at `http://localhost:3000`. 2. Make a request through the Tailscale proxy. The backend receives `x-tsdproxy-auth-token` in the request headers. 3. From the host, replay the token to the management API: ```bash # Capture token from backend headers (e.g., via a header-reflection endpoint) TOKEN=$(curl -s http://localhost:3000/debug/headers | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['headers'].get('X-Tsdproxy-Auth-Token',''))") # Replay from localhost to gain admin access curl -H "x-tsdproxy-auth-token: $TOKEN" \ -H "x-tsdproxy-id: attacker" \ http://127.0.0.1:8080/api/v1/proxies # Returns full proxy list with admin access ``` ## Fix Remove `HeaderAuthToken` from the outgoing backend request, and guard identity-header injection on `user.ID != ""`: ```go // port.go: only inject headers for actually authenticated users if identityHeaders { if user, ok := model.WhoisFromContext(r.In.Context()); ok && user.ID != "" { r.Out.Header.Set(consts.HeaderID, user.ID) // HeaderAuthToken should NOT be forwarded to backends } } ``` ## Impact An attacker with code execution in any backend proxied by tsdproxy (on the same host) gains full management API control: restart or pause all proxied services (DoS), enumerate all proxy configurations and backend network topology, and trigger webhook deliveries (SSRF via configured webhook URLs). ## Credits Reported by Vishal Shukla (@shukla304 / @therawdev). ## Sponsorship This audit is from an AI-assisted research agent at [sechub.dev](https://sechub.dev). Running it on OSS projects is free for maintainers.
CVSS v3.1
Score 9.0critical
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in TSDProxy arises because it forwards its internal authentication token (x-tsdproxy-auth-token) to all proxied backend services unconditionally when identityHeaders is enabled. This token is the secret used by the management HTTP server to trust forwarded identity claims. Since the token is forwarded regardless of user authentication state, a backend service that receives this token can replay it from localhost to the management API port (127.0.0.1:8080) with an arbitrary x-tsdproxy-id header, effectively bypassing Tailscale authentication. This enables an attacker with code execution in any backend on the same host to escalate privileges to full management API control. The vulnerability affects setups where the backend can access the management API via localhost, including non-Docker deployments and certain container network configurations. The recommended fix is to stop forwarding the auth token to backend services and only inject identity headers for authenticated users (user.ID != "").
Potential Impact
An attacker with code execution in any backend proxied by TSDProxy on the same host can gain full management API control. This includes the ability to restart or pause all proxied services, causing denial of service; enumerate all proxy configurations and backend network topology; and trigger webhook deliveries, potentially enabling server-side request forgery (SSRF) via configured webhook URLs. The vulnerability allows bypassing Tailscale authentication entirely by replaying the internal auth token from localhost.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix involves removing the x-tsdproxy-auth-token header from outgoing backend requests and only injecting identity headers for authenticated users (user.ID != ""). Until an official fix is available, avoid configurations where backend services can access the management API via localhost (127.0.0.1:8080), such as running backend and tsdproxy on the same host or using Docker host network mode. Monitor vendor advisories for an official patch or update.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-g936-7jqj-mwv8
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["Go"]
- Database Specific Severity
- CRITICAL
- Cvss Version
- 3.1
Threat ID: 6a520eab68715ace438f49ab
Added to database: 07/11/2026, 09:36:43 UTC
Last enriched: 07/11/2026, 09:46:17 UTC
Last updated: 07/31/2026, 12:27:30 UTC
Views: 32
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.