GHSA-P64J-F4X9-WQ66: OAuth Redirect URI Path Truncation in Ech0 Leads to Authorization Code Theft

Ech0 is a self-hosted lightweight publishing platform utilizing OAuth 2.0 for user authentication and authorization. The platform relies on an administrator-defined allowlist to restrict authorized callback endpoints during the OAuth flow. This mechanism restricts malicious actors from redirecting authenticated users to untrusted destinations and stealing their session tokens.

A vulnerability identified as GHSA-P64J-F4X9-WQ66 exists within the parseAndValidateClientRedirect function of the authentication service. The validation logic improperly verifies the redirect_uri parameter by only checking the scheme and host components of the requested URL. The implementation completely ignores the path, query, and fragment components during the validation sequence.

This flaw violates RFC 6749 §3.1.2, which mandates exact string matching for redirection endpoints to maintain security boundaries. The vulnerability allows an attacker to supply a crafted redirect_uri targeting a malicious path or open redirect on a trusted domain. Successful exploitation leads to the exposure of one-time authorization codes, enabling full account takeover.

The root cause resides in the custom URL parsing and validation logic implemented within internal/service/auth/auth.go. When an OAuth flow initiates, the application extracts the redirect_uri parameter and compares it against an array of permitted URLs defined in the application configuration. The developers implemented a partial comparison strategy instead of an exact string match.

The logic extracts the Scheme and Host properties from the parsed URL object and uses strings.EqualFold to perform a case-insensitive comparison against the permitted URL. If both components match, the function sets a boolean flag to true, approving the redirection attempt. The code drops the Path, RawQuery, and Fragment properties during this evaluation.

This structural oversight creates a significant security gap when the whitelisted domain hosts unauthenticated user-generated content, open redirects, or third-party analytical scripts. An attacker constructs a URI containing a trusted domain and an untrusted path, satisfying the validation constraints while directing the final application flow to a hostile endpoint.

An examination of the pre-patch source code reveals the precise nature of the logical flaw in the validation routine. The original implementation relied solely on scheme and host comparisons without analyzing the remaining URI segments.

// Pre-patch implementation in internal/service/auth/auth.go
if strings.EqualFold(redirectURL.Scheme, allowURL.Scheme) &&
   strings.EqualFold(redirectURL.Host, allowURL.Host) {
    matched = true
}

The patch introduced in commit a7e8b8e84bd1e3db090dfb720f2c6c433356b442 addresses this oversight by constructing normalized strings that incorporate the path component. The updated logic concatenates the lowercased scheme, host, and case-sensitive path before performing an exact string comparison.

// Post-patch implementation
redirectNorm := strings.ToLower(redirectURL.Scheme) + "://" +
    strings.ToLower(redirectURL.Host) + redirectURL.Path
allowNorm := strings.ToLower(allowURL.Scheme) + "://" +
    strings.ToLower(allowURL.Host) + allowURL.Path
 
if redirectNorm == allowNorm {
    matched = true
}

The developers also refactored the BindOAuth and GetOAuthLoginURL functions to enforce early validation. The patched application now verifies the requested redirection URI before generating and signing the state JWT. This structural change prevents the application from minting cryptographic tokens containing malicious payload data, eliminating the core exploitation primitive.

Exploitation of this vulnerability requires the attacker to construct a crafted OAuth authorization link and deliver it to a target user. The attacker sets the redirect_uri parameter to a hostile path on a permitted domain, such as an open redirect endpoint or a page containing third-party tracking scripts.

When the victim initiates the OAuth flow, the Ech0 server validates the truncated URI, generates a signed state JSON Web Token containing the complete malicious URI, and forwards the victim to the Identity Provider. After successful authentication, the Identity Provider redirects the victim back to the Ech0 callback endpoint, appending an authorization code and the unaltered state parameter.

The Ech0 server receives the callback, decodes the state token, and trusts the embedded redirect_uri because it carries a valid cryptographic signature generated by the server. The application then issues an HTTP 302 redirection, sending the victim and their authorization code to the attacker-controlled path. The attacker subsequently extracts the code via Referer header leakage or by capturing traffic from an open redirect chain.

The primary impact of this vulnerability is complete account takeover through authorization code theft. The stolen code allows the attacker to finalize the OAuth flow independently, binding their session to the victim's identity within the Ech0 platform.

An attacker exploiting this flaw gains unauthorized access to all application functions available to the compromised user. For a lightweight publishing platform, this access permits the unauthorized publication of articles, modification of existing content, and extraction of private data. If the victim holds administrative privileges, the attacker achieves total control over the platform.

The attack relies on specific environmental prerequisites to succeed. The attacker must identify an exploitable path on the trusted domain, and the victim must interact with the crafted link while holding an active session with the Identity Provider. Despite these constraints, the vulnerability presents a severe risk due to the complete circumvention of the application's authentication boundary.

The primary remediation strategy requires updating the Ech0 application to a version containing commit a7e8b8e84bd1e3db090dfb720f2c6c433356b442. Administrators must ensure the deployment utilizes the latest upstream code repository to mitigate the vulnerability effectively.

Application administrators should conduct a comprehensive audit of the Auth.Redirect.AllowedReturnURLs configuration setting. The whitelist must exclusively contain explicit, trusted endpoints necessary for operational requirements. Removing domains that host user-generated content or unauthenticated redirectors reduces the attack surface significantly.

Security teams can implement Web Application Firewall rules to detect and block incoming OAuth requests containing unexpected paths in the redirect_uri parameter. Furthermore, administrators should monitor server access logs for anomalous callback URIs, specifically searching for anomalies in the state parameter processing during authentication events.