CVE-2026-34969: 
vulnerability analysis and mitigation

CVE-2026-34969 is a refresh token disclosure vulnerability in Nhost's open-source auth service, where the OAuth provider callback flow places refresh tokens directly into redirect URLs as query parameters. This affects all versions of nhost/auth prior to 0.48.0 and impacts every OAuth provider flow (GitHub, Google, Apple, etc.) through the shared callback handler in services/auth/go/controller/sign_in_provider_callback_get.go. The vulnerability was published on March 31, 2026, and assigned a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 2.3 (Low), reflecting the constrained real-world exploitability due to one-time-use tokens and infrastructure-bounded leak vectors (GitHub Advisory, Github Advisory DB).

The root cause is in sign_in_provider_callback_get.go (lines 257–261), where the signinProviderProviderCallback function appends the refresh token to the redirect URL's query string using values.Add("refreshToken", session.RefreshToken), resulting in HTTP 302 redirects of the form Location: https://myapp.com/callback?refreshToken=<token>. This violates RFC 6749 Section 10.3, which explicitly prohibits including access or refresh tokens in redirect URIs, and maps to CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and CWE-598 (Use of GET Request Method With Sensitive Query Strings). The leak vectors include browser history, server/proxy/CDN access logs, and HTTP Referer headers sent to developer-integrated services, though modern browsers' default strict-origin-when-cross-origin referrer policy limits cross-origin Referer leakage (GitHub Advisory).

Successful exploitation allows an attacker with access to browser history, server logs, or proxy/CDN logs to obtain a valid refresh token and exchange it for a new access token, effectively hijacking the authenticated session. The impact is limited to confidentiality — there is no integrity or availability impact — and is further constrained by the one-time-use nature of refresh tokens, meaning exploitation requires racing the legitimate client to consume the token. All OAuth provider integrations (GitHub, Google, Apple, etc.) are affected through the same callback handler (GitHub Advisory, Github Advisory DB).

A proof-of-concept with step-by-step HTTP requests and a curl command to exchange a stolen token is publicly documented in the GitHub Security Advisory (GitHub Advisory). There is no evidence of active in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.042–0.063%, placing it in the 20th percentile for exploitation likelihood. The one-time-use nature of refresh tokens and the requirement for attacker access to owned infrastructure significantly limit practical exploitability (Github Advisory DB).

1. Reconnaissance: Identify a target application using Nhost's auth service (versions prior to 0.48.0) with OAuth login enabled.
2. Initiate OAuth flow: Send a GET request to the auth service's OAuth endpoint: GET /signin/provider/github?redirectTo=https://myapp.com/callback.
3. Complete OAuth with provider: The user (or attacker-controlled session) completes authentication with the OAuth provider (e.g., GitHub).
4. Capture the redirect: The auth service issues an HTTP 302 redirect containing the refresh token in the URL: Location: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890.
5. Harvest the token: Obtain the token from one of the leak vectors — browser history (local access), server/reverse proxy/CDN access logs, or HTTP Referer headers logged by integrated third-party services.
6. Exchange token for access: Use the stolen refresh token to obtain a new access token before the legitimate client consumes it:

curl -X POST https://auth.nhost.run/v1/token \
  -H 'Content-Type: application/json' \
  -d '{"refreshToken": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"}'

7. Achieve session hijacking: Use the returned access token to authenticate as the victim user (GitHub Advisory).

• Network: Unexpected POST requests to /v1/token on the Nhost auth service originating from unfamiliar IP addresses, particularly shortly after an OAuth callback redirect.
• Logs: Server access logs, reverse proxy logs, or CDN logs containing entries such as GET /callback?refreshToken=<uuid> — the presence of a refreshToken query parameter in access logs is itself the primary indicator of the vulnerable behavior.
• Logs: Multiple token exchange requests (POST /v1/token) for the same refresh token UUID within a short time window, which may indicate a race between the legitimate client and an attacker.
• Logs: HTTP Referer headers in integrated service logs (analytics, CDN) containing refreshToken= in the referrer URL, indicating token leakage via Referer.
• Browser/Client: Browser history entries on user devices containing URLs with refreshToken= query parameters in the callback path (GitHub Advisory).

Upgrade nhost/auth to version 0.48.0 or later, which implements PKCE (Proof Key for Code Exchange) for the OAuth flow, ensuring the authorization code cannot be exchanged without the original client's code_verifier even if the URL is logged (GitHub Advisory, Github Advisory DB). As interim mitigations, apply strict access controls and short retention policies on server access logs, proxy/CDN logs, and WAF logs to limit the window of token exposure. Additionally, audit any integrated third-party services (analytics, CDNs) that may receive Referer headers from the OAuth callback page, and consider configuring a Referrer-Policy: no-referrer header on the callback page. See the PKCE documentation for implementation guidance (Nhost PKCE Docs).

The vulnerability was reported by security researcher 0xkakash1 and disclosed responsibly through GitHub's security advisory process by Nhost maintainer dbarrosop on March 31, 2026 (GitHub Advisory). No significant broader media coverage or notable social media commentary beyond the advisory itself has been identified.