CVE-2026-79662 in Ech0
Summary
by MITRE • 08/25/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified within Ech0 versions through 4.5.6 represents a critical flaw in the OAuth2 authorization code flow implementation, specifically located in the parseAndValidateClientRedirect function found in the internal service authentication module. This defect stems from an insufficient validation mechanism when processing client-supplied redirect URIs during the login process. The system is designed to verify that the requested redirection destination belongs to a pre-configured allowlist of trusted origins; however, this verification logic is fundamentally incomplete as it performs a comparison based solely on the URI scheme and host components while entirely disregarding the path, query string, and fragment identifiers. This oversight creates a significant security gap because the validation does not ensure that the redirect destination matches an expected endpoint or parameter structure defined by the application's security policy.
During the authentication sequence, the system embeds the client-supplied redirect_uri into a signed JSON Web Token (JWT) designated as the state parameter. While the JWT itself is cryptographically protected against tampering, it serves to carry the intended redirection target back to the client after authorization. Because the initial validation step failed to restrict or normalize the path and query components of the URI, an attacker can supply a redirect_uri that shares the same host and scheme as an allowed origin but contains maliciously crafted paths or parameters. This allows the application to treat the request as legitimate based on its incomplete checks, thereby proceeding with the OAuth exchange without raising any security alerts or rejecting the malformed input.
The operational impact of this vulnerability is severe due to the potential for credential theft via token leakage. Upon completion of the OAuth flow, the authorization server redirects the user agent to the crafted URI containing a one-time authorization code in the query string. If an attacker can influence how that specific host handles requests or if there are other vulnerabilities such as open redirect issues on the allowed domain, they may intercept this sensitive authorization code through various side-channel attacks. Common vectors for such leakage include HTTP Referer headers sent to third-party analytics services, cross-site scripting exploits that exfiltrate URL data, or server-side request forgery scenarios where the victim's browser is tricked into sending the token-containing URI to an attacker-controlled endpoint.
Once the authorization code has been successfully intercepted by the adversary, they can exploit a subsequent API endpoint to finalize the compromise. The application exposes a public POST /api/auth/exchange endpoint designed to convert these temporary codes into long-lived access and refresh tokens for the authenticated user. By submitting the stolen one-time exchange code to this endpoint, an attacker can obtain valid session credentials belonging to the victim. This effectively bypasses multi-factor authentication protections if they were only applied during the initial login phase, granting the adversary full administrative or user-level access depending on the compromised account's privileges and persisting as long as the refresh tokens remain valid.
From a classification perspective, this vulnerability aligns with CWE-601, which describes URL Redirection to Untrusted Site (Open Redirect), although in this specific context it is more accurately characterized by CWE-284, Improper Access Control, due to the failure of the authorization server to properly validate input before processing sensitive state transitions. Furthermore, within the MITRE ATT&CK framework, this attack vector maps to T1076, Default Web Browser Redirects, and potentially T1539, Steal Web Session Cookie, as the ultimate goal is to hijack the user's authenticated session by stealing tokens that function similarly to cookies in maintaining state. The flaw highlights a common pitfall where developers assume that validating the domain of a redirect URI is sufficient for security, neglecting the need to validate the entire resource path and query parameters against strict allowlists or expected patterns.
Mitigation strategies must focus on implementing rigorous input validation at the point of initial request processing. Developers should ensure that the parseAndValidateClientRedirect function performs a comprehensive comparison of the entire redirect URI structure, including scheme, host, port, path, and query string, against an explicit allowlist rather than relying solely on domain matching. Alternatively, if dynamic paths are required for legitimate use cases, the system should enforce strict regex patterns or parameter whitelisting to ensure that only expected values can be passed in the redirect URI components. Upgrading to version 4.7.3 is the primary remediation step as it addresses this logic error by correcting the validation routine to inspect all relevant parts of the URI before embedding them into the state JWT, thereby preventing attackers from injecting malicious paths or parameters that could lead to token leakage and subsequent account takeover.