Summary

GetWorkspaceProxyByHostname validated a redirect target's host with a PostgreSQL SIMILAR TO pattern ('[^:]*://' || hostname || '([:/]?%)*') that was effectively a prefix match rather than an exact-host match. Because the trailing delimiter group was optional ([:/]?), any host that is a string prefix of a configured workspace-proxy access URL was treated as a trusted proxy (for example syd.co matched syd.coder-proxy.example.com).

Note: Practical exploitation requires an authenticated victim to open an attacker-crafted auth-redirect link, and the attacker to own a domain that is a string prefix of a real workspace-proxy access URL.

Impact

When an authenticated victim opens a crafted /api/v2/applications/auth-redirect?redirect_uri=... link, Coder treats the attacker's prefix domain as a trusted proxy, mints an application_connect-scoped API key for the victim, and 302-redirects the browser to the attacker's domain with the encrypted key in the query string. The key is not bound to the host it was issued for, so the attacker can replay the blob against the genuine proxy within its validity window and obtain a cookie carrying the victim's full-lifetime application_connect key, granting access to the victim's workspace apps.

Patches

The fix requires a hostname boundary after the hostname: either end of string, or : for a port, or / for a path (([:/]%)*). URLs whose host exactly matches the candidate, including URLs with ports or paths, still match. A hostname that is merely a prefix of the configured host no longer matches.

The fix was backported to all supported release lines:

Release lines 2.30 through 2.32 are end-of-life and will not receive a patch.

Workarounds

There is no configuration-only workaround. Upgrade to a patched release. Deployments that do not use workspace proxies are not affected.

Credits

We'd like to thank Anthropic's Security Team (ANT-2026-FXER0JGJ) and Adam Korczynski of Ada Logics for validating and reporting this issue.