The workspace app proxy in github.com/coder/coder/v2 resolves the target app from httpapi.RequestHost(), which prioritizes the X-Forwarded-Host header over the actual Host header. Because no middleware strips or validates this header and it is not restricted by browsers, client-side JavaScript can set it in fetch() calls. When subdomain app routing (wildcard hostname) is enabled and the upstream proxy does not remove X-Forwarded-Host, an attacker controlling a shared workspace app can send requests with a forged X-Forwarded-Host pointing to a victim's private app. The server routes based on this attacker-controlled header but authorizes using the victim's session cookie scoped to the wildcard domain, allowing the attacker to read private app responses. The vulnerability is fixed by trusting X-Forwarded-Host only from configured trusted proxies and otherwise using the verified request host. The fix is backported to all supported release lines including 2.34.2, 2.33.8, 2.32.7, and 2.29.17.

An attacker who controls a shared workspace app can exploit this vulnerability to read private app data of other users by forging the X-Forwarded-Host header. This leads to unauthorized disclosure of sensitive information scoped to subdomain app routing environments. The attack requires specific deployment conditions: subdomain app routing enabled and no upstream proxy stripping the X-Forwarded-Host header. The vulnerability does not affect availability or integrity but results in a confidentiality breach.

A fix is available and has been backported to all supported release lines: 2.34.2, 2.33.8, 2.32.7, and 2.29.17. Users should upgrade to these versions or later. As a workaround, deploy an upstream reverse proxy that strips or overwrites the X-Forwarded-Host header on untrusted requests to prevent exploitation. The fix ensures that X-Forwarded-Host is trusted only from configured trusted proxies and otherwise uses the verified request host for routing.