Summary
Coder contains an improper hostname validation flaw that can cause a domain resembling a trusted workspace-proxy hostname to be accepted as legitimate. An attacker controlling such a domain may trick an authenticated user into opening a crafted redirect link, capture an application connection API key, and replay it to access the user's workspace applications.
Coder contains an improper hostname validation flaw that can cause a domain resembling a trusted workspace-proxy hostname to be accepted as legitimate. An attacker controlling such a domain may trick an authenticated user into opening a crafted redirect link, capture an application connection API key, and replay it to access the user's workspace applications.
Affected context
The issue occurs in Coder deployments that use workspace proxies and process application authentication redirects through hostname-based proxy lookup. Risk arises when hostname matching treats a string prefix as equivalent to a complete, valid hostname, allowing an attacker-controlled domain to be trusted as a workspace-proxy access URL. Exploitation also depends on an authenticated victim following a crafted link.
The issue occurs in Coder deployments that use workspace proxies and process application authentication redirects through hostname-based proxy lookup. Risk arises when hostname matching treats a string prefix as equivalent to a complete, valid hostname, allowing an attacker-controlled domain to be trusted as a workspace-proxy access URL. Exploitation also depends on an authenticated victim following a crafted link.
Exploit preconditions
- Attack surface: Workspace application authentication and proxy resolution endpoints
- Required access: Control of a domain that begins with a trusted workspace-proxy hostname, plus the ability to lure an authenticated user to a crafted link
- Trigger point: Processing of an
/api/v2/applications/auth-redirectrequest - Why exploitation is possible: Prefix-based hostname matching can trust attacker-controlled domains, allowing an application connection API key to be redirected to and captured by the attacker
- Attack surface: Workspace application authentication and proxy resolution endpoints
- Required access: Control of a domain that begins with a trusted workspace-proxy hostname, plus the ability to lure an authenticated user to a crafted link
- Trigger point: Processing of an
/api/v2/applications/auth-redirectrequest - Why exploitation is possible: Prefix-based hostname matching can trust attacker-controlled domains, allowing an application connection API key to be redirected to and captured by the attacker
Why this happens
The underlying bug is an improper hostname validation pattern in which a SQL SIMILAR TO expression performs a prefix match rather than enforcing an exact hostname or properly delimited domain relationship. This causes a domain that merely begins with a trusted workspace-proxy access URL to be treated as trusted. The resulting trust-boundary failure can expose authentication material and maps to CWE-522, which covers insufficient protection of credentials.
The underlying bug is an improper hostname validation pattern in which a SQL SIMILAR TO expression performs a prefix match rather than enforcing an exact hostname or properly delimited domain relationship. This causes a domain that merely begins with a trusted workspace-proxy access URL to be treated as trusted. The resulting trust-boundary failure can expose authentication material and maps to CWE-522, which covers insufficient protection of credentials.
Potential impact
- An attacker may capture an application connection API key
- The captured key could be replayed to access the victim's workspace applications
- Unauthorized users may gain access to application data or actions available through the affected workspace
- A successful attack could expose credentials beyond the originally intended redirect context
- An attacker may capture an application connection API key
- The captured key could be replayed to access the victim's workspace applications
- Unauthorized users may gain access to application data or actions available through the affected workspace
- A successful attack could expose credentials beyond the originally intended redirect context
General mitigation guidance
Mitigation generally focuses on making hostname trust decisions exact, canonical, and resistant to ambiguous parsing.
Common defensive patterns include:
- Requiring exact hostname matches or explicitly delimited subdomain relationships
- Avoiding prefix-only comparisons for security-sensitive host validation
- Canonicalizing hostnames consistently before comparison
- Restricting redirect destinations to an explicit allowlist
- Limiting the scope, lifetime, and privileges of application connection credentials
- Avoiding placement of sensitive tokens in redirect flows where attacker-controlled destinations may be reached
- Applying least privilege to workspace application access and requiring additional authorization for high-impact operations
Mitigation generally focuses on making hostname trust decisions exact, canonical, and resistant to ambiguous parsing.
Common defensive patterns include:
- Requiring exact hostname matches or explicitly delimited subdomain relationships
- Avoiding prefix-only comparisons for security-sensitive host validation
- Canonicalizing hostnames consistently before comparison
- Restricting redirect destinations to an explicit allowlist
- Limiting the scope, lifetime, and privileges of application connection credentials
- Avoiding placement of sensitive tokens in redirect flows where attacker-controlled destinations may be reached
- Applying least privilege to workspace application access and requiring additional authorization for high-impact operations
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review rules targeting prefix-based hostname comparisons
- Review of SQL
LIKEorSIMILAR TOexpressions used in authorization and proxy-selection logic - Tests covering attacker-controlled domains that share a trusted hostname prefix
- Policy checks requiring canonicalization and exact allowlist validation for redirect destinations
- Monitoring for unusual application authentication redirects, API key reuse, and access from domains outside approved proxy boundaries
Automated security review tools may help identify unsafe comparison patterns, but behavioral tests should verify the complete trust decision.
Organizations can look for this class of issue through:
- Static analysis and code review rules targeting prefix-based hostname comparisons
- Review of SQL
LIKEorSIMILAR TOexpressions used in authorization and proxy-selection logic - Tests covering attacker-controlled domains that share a trusted hostname prefix
- Policy checks requiring canonicalization and exact allowlist validation for redirect destinations
- Monitoring for unusual application authentication redirects, API key reuse, and access from domains outside approved proxy boundaries
Automated security review tools may help identify unsafe comparison patterns, but behavioral tests should verify the complete trust decision.
