Ech0 CVE-2026-79662

Exploitation requires that the Ech0 instance has OAuth authentication enabled and at least one entry present in the admin-configured redirect URI allowlist. The attacker must identify a page on an allowlisted host that leaks the full page URL to an external party - via a Referer header on outbound links or subresource loads, a JavaScript analytics beacon that captures window.location.href, or a separate open redirect on that host that forwards the query string. The victim must be induced to follow an attacker-crafted OAuth login link, constituting required user interaction (CVSS UI:P). The exchange code is single-use, meaning the attacker must capture and redeem it before the legitimate flow consumes it or it expires. Exploitation is bounded to OAuth-enabled deployments with allowlisted hosts that have one of the described leakage vectors; instances with only local authentication or allowlists restricted to paths with strict outbound referrer suppression present a materially lower attack surface.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N, score 8.8) accurately captures the attack profile: network-accessible, no authentication required, but dependent on two chained conditions - victim interaction and a secondary code-leakage channel on the allowlisted host. The high attack complexity and partial attack requirements (AT:P) meaningfully constrain mass exploitation: the attacker must identify or control a page on an allowlisted origin that leaks the full URL to an external party. There is no EPSS data in the provided intelligence, so statistical exploitation probability cannot be quantified. The vulnerability is not listed in CISA KEV, meaning active exploitation is unconfirmed. However, the GHSA advisory contains full source code evidence and a clear exploitation narrative, significantly lowering the skill barrier for targeted attacks. The subsequent-system high confidentiality and integrity impact (SC:H/SI:H) reflects that stolen tokens grant full impersonation on any resource server that trusts them. This is not a high-CVSS-but-low-real-risk case: the impact of token theft is severe, and the attack is realistic against deployments whose allowlisted hosts carry any analytics, CDN scripts, or open redirects - a common condition in web applications.

An attacker discovers that https://myapp.example.com/dashboard is in the Ech0 OAuth allowlist and that https://myapp.example.com/news embeds a third-party analytics tag that fires a beacon containing the full page URL. The attacker crafts a login link pointing to https://ech0-instance.example.com/oauth/google/login?redirect_uri=https://myapp.example.com/news, passes the scheme+host check, and emails it to the victim. After the victim authenticates with Google, Ech0 redirects their browser to https://myapp.example.com/news?code=ONE_TIME_CODE; the analytics beacon transmits the full URL to the attacker's collection server. The attacker immediately calls POST /api/auth/exchange with the stolen code and receives the victim's access and refresh tokens, achieving full account takeover. The public advisory provides sufficient technical detail for a skilled attacker to reproduce this without a pre-built POC.