CVE-2026-79662: Ech0 before 4.7.3 OAuth Redirect URI Validation Bypass
Ech0 through 4.5.6 contains an OAuth redirect URI validation vulnerability in parseAndValidateClientRedirect (internal/service/auth/auth.go) that compares only the scheme and host of the client-supplied redirecturi against the admin-configured allowlist, ignoring path, query, and fragment components. The redirecturi is embedded into the signed state JWT at login time without validation. An attacker can craft a redirecturi whose host matches an allowed origin but whose path is attacker-influenced; after the OAuth exchange the victim is redirected to that path with a one-time exchange code in the query string. If the code leaks (e.g., via Referer, analytics, or an open redirect on that host), the attacker can trade it at the public POST /api/auth/exchange endpoint for the victim's access and refresh tokens. Fixed in 4.7.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Ech0to a version that resolves this vulnerability.Fixed in 4.7.3Patch Ech0 before 4.7.3 OAuth Redirect URI Validation Bypass - Configuration
Update OAuth redirect URI validation so that parseAndValidateClientRedirect compares the full redirect_uri (scheme, host, and also path/query/fragment) against the allowlist; do not ignore path, query, or fragment components.
Ech0 OAuth redirect URI allowlist validation (parseAndValidateClientRedirect in internal/service/auth/auth.go) redirect_uri validation components = must include path, query, and fragment (not only scheme and host)
Event History
Frequently Asked Questions
Which deployments are exposed?
Ech0 versions through 4.5.6 are identified as affected. Exploitation depends on OAuth being used and on an attacker being able to supply a redirect URI with the same scheme and host as an administrator-allowed redirect origin.
What must happen for an attacker to obtain tokens?
The attacker must induce a victim to complete the OAuth flow using a crafted redirect URI. The resulting one-time exchange code must then leak from the redirected path, such as through a Referer header, analytics, or an open redirect on the allowed host; the attacker can exchange that code at POST /api/auth/exchange for access and refresh tokens.
Are path and query restrictions in the redirect allowlist effective?
No. The vulnerable validation compares only the scheme and host of the supplied redirect URI, ignoring its path, query, and fragment components. An allowed origin therefore does not prevent redirects to attacker-influenced paths on that origin.
What is the available remediation?
Upgrade to Ech0 4.7.3, which fixes the issue. The provided information does not identify an interim mitigation.