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 redirect_uri against the admin-configured allowlist, ignoring path, query, and fragment components. The redirect_uri is embedded into the signed state JWT at login time without validation. An attacker can craft a redirect_uri 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.

Ech0 versions through 4.5.6 contain an OAuth redirect URI validation vulnerability in the parseAndValidateClientRedirect function (internal/service/auth/auth.go). The validation logic only compares the scheme and host of the client-supplied redirect_uri against an admin-configured allowlist, ignoring path, query, and fragment components. The unvalidated redirect_uri is embedded into a signed state JWT at login time. An attacker can craft a redirect_uri with a matching host but an attacker-controlled path; 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 via Referer headers, analytics, or an open redirect on the allowed host, the attacker can redeem it at the public POST /api/auth/exchange endpoint to obtain the victim's access and refresh tokens, effectively achieving account takeover. The vulnerability has been fixed in version 4.7.3.