CVE-2026-55430: Coder: X-Forwarded-Host spoof leaks victim app data

### 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: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### 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!

An organization runs Coder with wildcard subdomain app routing enabled for its AI engineering team's cloud dev sandboxes, and its edge proxy does not strip X-Forwarded-Host. An attacker with access to their own (or a compromised) shared workspace app hosts malicious JavaScript there and shares the link with a colleague, or gets it surfaced via an internal app gallery. The victim, already authenticated with a session cookie scoped to the shared parent domain, opens the attacker's app. The malicious script fires same-site fetch() calls with X-Forwarded-Host forged to the victim's private app subdomain; the untrusted proxy routes the request there, but authorization still relies on the cookie the browser auto-attaches — the victim's own credential. The attacker's page reads back the response, exfiltrating whatever the victim's private app (e.g., an AI agent's workspace UI, notebook, or terminal proxy) rendered, without ever needing the victim's actual credentials.