CVE-2026-55430: Coder App Proxy Host-Header Validation Weakness

Technical summary

The workspace app proxy in Coder resolves routing targets using `httpapi.RequestHost()`, which prioritizes the `X-Forwarded-Host` header over the canonical `Host` header. In deployments using wildcard hostname routing for apps, an attacker with valid authentication can inject a forged `X-Forwarded-Host` value via client-side JavaScript to redirect proxy traffic to an unintended application. The header is not browser-restricted, and no middleware strips it before routing logic executes. The fix implements trusted-proxy validation: only proxies explicitly configured as trusted are allowed to set `X-Forwarded-Host`; otherwise, the routing host is derived from the verified request `Host` header. The vulnerability is classified as CWE-345 (Insufficient Verification of Data Source) and CWE-441 (Unintended Proxy/Intermediary).

Business impact

This vulnerability enables a low-privilege Coder user to intercept or redirect traffic to applications they should not access, potentially exposing sensitive development environments, secrets, or configuration data hosted on the same deployment. The confidentiality risk is high—an attacker gains unauthorized visibility into another user's workspace app without modifying or deleting it. Organizations relying on application isolation within Coder deployments for multi-tenant or segregated team access are at risk if their infrastructure does not strip untrusted headers.

Affected systems

Coder versions prior to 2.29.7, 2.32.7, 2.33.8, and 2.34.2 are affected. The vulnerability is exploitable only if: (1) subdomain-based app routing (wildcard hostname) is enabled, (2) the Coder deployment uses `X-Forwarded-Host` for routing decisions, and (3) the upstream reverse proxy or load balancer does not strip or validate this header. Deployments behind properly configured proxies that reject untrusted `X-Forwarded-Host` values are not vulnerable.

Exploitability

Exploitation requires an authenticated Coder user, a victim who clicks a link to visit the attacker's shared app, and a vulnerable deployment configuration. An attacker cannot exploit this from outside the organization without valid credentials. The attack surface is further limited by the need for subdomain routing and an upstream proxy that does not filter the header. However, once conditions align, a standard web browser and client-side JavaScript make the attack trivial to execute—no special tools or network position required.

Remediation

Upgrade Coder to version 2.29.7, 2.32.7, 2.33.8, or 2.34.2 (or later in each series). For deployments that cannot patch immediately, implement an upstream reverse proxy (nginx, HAProxy, AWS CloudFront, etc.) configured to strip or rewrite the `X-Forwarded-Host` header on requests from untrusted clients. Additionally, review deployment topology: if subdomain app routing is not required, disable it to reduce attack surface.

Patch guidance

Verify the Coder version in your deployment using `coder version` or your deployment dashboard. Upgrade to the patched versions listed in the vulnerability description for your major version line. For example, if running 2.32.x, upgrade to 2.32.7 or later. Test the upgrade in a staging environment to ensure app routing and proxy behavior remain correct. After patching, confirm via logs or admin interface that app routing resolves correctly and that `X-Forwarded-Host` is only trusted from configured proxies.

Detection guidance

Monitor HTTP access logs for anomalous `X-Forwarded-Host` header values that differ from the canonical `Host` header, especially from authenticated users accessing shared apps. Look for repeated requests with mismatched host values targeting different applications in sequence—a sign of reconnaissance or redirection attempts. Enable debug logging in Coder if available to trace app routing decisions. Network segmentation can help: if you cannot patch immediately, use WAF rules or proxy rules to reject requests with suspicious or mismatched `X-Forwarded-Host` values.

Why prioritize this

Although the CVSS score is moderate (5.8), the confidentiality risk in multi-tenant or team-segregated Coder deployments is material. The vulnerability is readily exploitable by any authenticated user and does not require advanced techniques or network access. Organizations using Coder for sensitive workloads or compliance-critical environments should prioritize patching, especially if they cannot immediately deploy header-stripping proxies. The low authentication bar and high user-interaction likelihood make this a practical risk in real-world deployments.

Risk score, explained

The CVSS score of 5.8 (MEDIUM) reflects a high confidentiality impact (C:H) and high attack complexity (AC:H) tied to strict configuration and proxy requirements. The attack requires low-privilege authentication (PR:L), user interaction (UI:R), and a specific deployment posture. Scope is changed (S:C) because the attacker crosses trust boundaries between applications. No integrity or availability impact is present. Organizations operating without the required preconditions (wildcard routing, non-filtering upstream proxy) face reduced risk.

Frequently asked questions