GHSA-g936-7jqj-mwv8: TSDProxy: Internal proxy auth token forwarded to backend services enables management API escalation
TSDProxy forwards an internal per-process authentication token to all proxied backend services when identityHeaders is enabled by default. This token is used by the management HTTP server to trust forwarded identity claims. A backend receiving this token can replay it locally to the management API with an arbitrary identity header, bypassing authentication. This allows an attacker with code execution in any backend on the same host to gain full management API control, including restarting or pausing services, enumerating proxy configurations, and triggering webhook deliveries. The vulnerability affects deployments where the backend can reach 127.0.0.1:8080, such as non-Docker hosts, Docker containers in host network mode, or containers sharing the proxy's network namespace. The fix involves removing the auth token from backend requests and only injecting identity headers for authenticated users.
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.
GHSA-g936-7jqj-mwv8: TSDProxy: Internal proxy auth token forwarded to backend services enables management API escalation
Description
TSDProxy forwards an internal per-process authentication token to all proxied backend services when identityHeaders is enabled by default. This token is used by the management HTTP server to trust forwarded identity claims. A backend receiving this token can replay it locally to the management API with an arbitrary identity header, bypassing authentication. This allows an attacker with code execution in any backend on the same host to gain full management API control, including restarting or pausing services, enumerating proxy configurations, and triggering webhook deliveries. The vulnerability affects deployments where the backend can reach 127.0.0.1:8080, such as non-Docker hosts, Docker containers in host network mode, or containers sharing the proxy's network namespace. The fix involves removing the auth token from backend requests and only injecting identity headers for authenticated users.
CVSS v3.1
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/12/2026, 03:35:04 UTC
Views: 8
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.