EUVD-2026-42136
GHSA-5g4w-3vw9-478w
Severity by source
AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N
Requires network access but stacked conditions (subdomain routing, no proxy stripping, victim interaction) justify AC:H; attacker needs a shared app account (PR:L); scope changes as routing crosses user-app trust boundaries.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
3DescriptionNVD
Summary
The workspace app proxy resolves the target app from httpapi.RequestHost() which prefers the X-Forwarded-Host header over the real Host header. No middleware strips X-Forwarded-Host before routing and the header is not browser-forbidden so client-side JavaScript can set it on fetch() calls.
> Note: Practical exploitation requires subdomain app routing (wildcard hostname) enabled, a victim who visits the attacker's shared app and a deployment whose upstream proxy does not strip X-Forwarded-Host.
Impact
App session cookies are scoped to the wildcard parent domain so the browser attaches them to any app subdomain. An attacker who controls a shared workspace app can serve JavaScript that sends same-site requests with a forged X-Forwarded-Host pointing at a victim's private app. The server routes by the attacker-controlled header but authorizes with the victim's cookie which lets the attacker read the victim's private app responses. Subdomain app routing must be enabled and no upstream proxy may strip X-Forwarded-Host.
Patches
The fix trusts X-Forwarded-Host only from configured trusted proxies and otherwise resolves the routing host from the verified request host.
The fix was backported to all supported release lines:
Workarounds
Place an upstream reverse proxy that strips or overwrites X-Forwarded-Host on untrusted requests.
Resources
- Fix: #26204
Credits
Coder would like to thank Anthropic's Security Team (ANT-2026-22435) for independently disclosing this issue!
AnalysisAI
Cross-boundary information disclosure in Coder's workspace app proxy allows an attacker who controls a shared workspace app to read a victim user's private app responses by forging the X-Forwarded-Host header. The proxy trusts this client-supplied header for routing decisions while simultaneously authorizing the request with the victim's own session cookie - which the browser attaches to any subdomain because cookies are scoped to the wildcard parent domain - enabling the attacker to steer responses from private apps back through their own JavaScript. Exploitation requires subdomain app routing (wildcard hostname) to be enabled and the victim to visit the attacker's shared app; no public exploit code or CISA KEV listing has been identified at time of analysis.
Technical ContextAI
Coder is a self-hosted remote development environment (Go package pkg:go/github.com_coder_coder_v2) that proxies browser access to workspace applications via a shared subdomain namespace. The vulnerable function httpapi.RequestHost() implements an X-Forwarded-Host preference over the real Host header - a common pattern for reverse-proxy-aware applications - but no middleware strips this header from untrusted client connections before it reaches the routing layer. Because Coder issues app session cookies scoped to the wildcard parent domain (e.g., *.coder.example.com), any subdomain - including attacker-controlled shared apps - receives those cookies on outbound requests. CWE-345 (Insufficient Verification of Data Authenticity) captures the root cause: the proxy fails to verify that the routing hint originates from a trusted upstream rather than from the end client. The X-Forwarded-Host header is not browser-forbidden (unlike some headers), meaning standard Fetch API calls from JavaScript can set it freely, making this exploitable purely from client-side script without any special browser exploitation.
RemediationAI
The primary fix is to upgrade to a patched release: v2.34.2, v2.33.8, v2.32.7, or v2.29.17 (ESR), all available at https://github.com/coder/coder/releases. The fix changes the routing logic to trust X-Forwarded-Host only when it originates from configured trusted proxies, falling back to the verified request Host header for all other connections. For deployments that cannot immediately upgrade, the documented workaround is to place an upstream reverse proxy (nginx, Caddy, Traefik, etc.) that explicitly strips or overwrites the X-Forwarded-Host header on all requests from untrusted clients before they reach Coder; note this workaround requires the reverse proxy to be in the request path for all app-subdomain traffic and does not protect deployments where Coder is directly internet-facing. The upstream fix PR is available at https://github.com/coder/coder/pull/26204.
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today