Skip to main content
Press slash or control plus K to focus the search. Use the arrow keys to navigate results and press enter to open a threat.
Reconnecting to live updates…

TSDProxy: Internal proxy auth token forwarded to backend services enables management API escalation

0
Critical
Published: 07/10/2026 (07/10/2026, 21:43:13 UTC)
Source: GCVE Database
Product: github.com/almeidapaulopt/tsdproxy

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

Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

Affected software

Goghsa
github.com/almeidapaulopt/tsdproxy
Affected versions
<1.4.4-0.20260603142855-434819b4421e

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

AILast updated: 07/11/2026, 09:46:17 UTC

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.

Pro Console: star threats, build custom feeds, automate alerts via Slack, email & webhooks.Upgrade to Pro

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 reviews

Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.

Sort by
Loading community insights…

Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.

Actions

PRO

Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.

Please log in to the Console to use AI analysis features.

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

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses