GHSA-G2QJ-PRGH-4G9R
Vulnerability from github – Published: 2026-04-01 23:36 – Updated: 2026-04-06 23:25Refresh Token Leaked via URL Query Parameter in OAuth Provider Callback
Summary
The auth service's OAuth provider callback flow places the refresh token directly into the redirect URL as a query parameter. Refresh tokens in URLs are logged in browser history, server access logs, HTTP Referer headers, and proxy/CDN logs.
Note that the refresh token is one-time use and all of these leak vectors are on owned infrastructure or services integrated by the application developer.
Affected Component
- Repository:
github.com/nhost/nhost - Service:
services/auth - File:
services/auth/go/controller/sign_in_provider_callback_get.go - Function:
signinProviderProviderCallback(lines 257-261)
Root Cause
In sign_in_provider_callback_get.go:257-261, after successful OAuth sign-in, the refresh token is appended as a URL query parameter:
if session != nil {
values := redirectTo.Query()
values.Add("refreshToken", session.RefreshToken)
redirectTo.RawQuery = values.Encode()
}
This results in a redirect like:
HTTP/1.1 302 Found
Location: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890
Proof of Concept
Step 1: Initiate OAuth login
GET /signin/provider/github?redirectTo=https://myapp.com/callback
Step 2: Complete OAuth flow with provider
Step 3: Auth service redirects with token in URL
HTTP/1.1 302 Found
Location: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890
Step 4: Token is now visible in owned infrastructure and services:
Browser History:
# User's browser history now contains the refresh token
HTTP Referer Header:
# If the callback page loads ANY external resource (image, script, etc.):
GET /resource.js HTTP/1.1
Host: cdn.example.com
Referer: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-...
# Note: modern browsers default to strict-origin-when-cross-origin policy,
# which strips query parameters from cross-origin Referer headers.
# Additionally, the Referer is only sent to services integrated by the
# application developer (analytics, CDNs, etc.), not arbitrary third parties.
Server Access Logs:
# Reverse proxy, CDN, or load balancer logs on owned infrastructure:
2026-03-08 12:00:00 GET /callback?refreshToken=a1b2c3d4-e5f6-... 200
Step 5: Attacker uses stolen refresh token
# Exchange stolen refresh token for new access token
curl -X POST https://auth.nhost.run/v1/token \
-H 'Content-Type: application/json' \
-d '{"refreshToken": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"}'
# Note: refresh tokens are one-time use, so this only works if the
# legitimate client has not already consumed the token and if the attacker has
# compromised your infrastructure to get access to this information
Impact
-
Session Hijacking: Anyone who obtains the token before it is consumed by the legitimate client can generate new access tokens, though the refresh token is one-time use and cannot be reused after consumption.
-
Leak Vectors: URL query parameters are visible in owned infrastructure and integrated services:
- Browser history (local access)
- HTTP Referer headers (mitigated by modern browser default referrer policies; only sent to developer-integrated services)
- Server access logs (owned infrastructure)
-
Proxy/CDN/WAF logs (owned infrastructure)
-
Affects All OAuth Providers: Every OAuth provider flow (GitHub, Google, Apple, etc.) goes through the same callback handler.
Fix
Implemented PKCE (Proof Key for Code Exchange) for the OAuth flow. With PKCE, the authorization code cannot be exchanged without the code_verifier that only the original client possesses, preventing token misuse even if the URL is logged.
See: https://docs.nhost.io/products/auth/pkce/
Resources
- OWASP: Session Management - Token Transport: "Session tokens should not be transported in the URL"
- RFC 6749 Section 10.3: "Access tokens and refresh tokens MUST NOT be included in the redirect URI"
- CWE-598: Use of GET Request Method With Sensitive Query Strings
- CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nhost/nhost"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260330133707-294954e0fc3a"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34969"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-598"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T23:36:10Z",
"nvd_published_at": "2026-04-06T16:16:38Z",
"severity": "LOW"
},
"details": "# Refresh Token Leaked via URL Query Parameter in OAuth Provider Callback\n\n## Summary\n\nThe auth service\u0027s OAuth provider callback flow places the refresh token directly into the redirect URL as a query parameter. Refresh tokens in URLs are logged in browser history, server access logs, HTTP Referer headers, and proxy/CDN logs.\n\nNote that the refresh token is one-time use and all of these leak vectors are on owned infrastructure or services integrated by the application developer.\n\n## Affected Component\n\n- **Repository**: `github.com/nhost/nhost`\n- **Service**: `services/auth`\n- **File**: `services/auth/go/controller/sign_in_provider_callback_get.go`\n- **Function**: `signinProviderProviderCallback` (lines 257-261)\n\n## Root Cause\n\nIn `sign_in_provider_callback_get.go:257-261`, after successful OAuth sign-in, the refresh token is appended as a URL query parameter:\n\n```go\nif session != nil {\n values := redirectTo.Query()\n values.Add(\"refreshToken\", session.RefreshToken)\n redirectTo.RawQuery = values.Encode()\n}\n```\n\nThis results in a redirect like:\n```\nHTTP/1.1 302 Found\nLocation: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890\n```\n\n## Proof of Concept\n\n### Step 1: Initiate OAuth login\n```\nGET /signin/provider/github?redirectTo=https://myapp.com/callback\n```\n\n### Step 2: Complete OAuth flow with provider\n\n### Step 3: Auth service redirects with token in URL\n```\nHTTP/1.1 302 Found\nLocation: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-7890-abcd-ef1234567890\n```\n\n### Step 4: Token is now visible in owned infrastructure and services:\n\n**Browser History:**\n```\n# User\u0027s browser history now contains the refresh token\n```\n\n**HTTP Referer Header:**\n```\n# If the callback page loads ANY external resource (image, script, etc.):\nGET /resource.js HTTP/1.1\nHost: cdn.example.com\nReferer: https://myapp.com/callback?refreshToken=a1b2c3d4-e5f6-...\n# Note: modern browsers default to strict-origin-when-cross-origin policy,\n# which strips query parameters from cross-origin Referer headers.\n# Additionally, the Referer is only sent to services integrated by the\n# application developer (analytics, CDNs, etc.), not arbitrary third parties.\n```\n\n**Server Access Logs:**\n```\n# Reverse proxy, CDN, or load balancer logs on owned infrastructure:\n2026-03-08 12:00:00 GET /callback?refreshToken=a1b2c3d4-e5f6-... 200\n```\n\n### Step 5: Attacker uses stolen refresh token\n```bash\n# Exchange stolen refresh token for new access token\ncurl -X POST https://auth.nhost.run/v1/token \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"refreshToken\": \"a1b2c3d4-e5f6-7890-abcd-ef1234567890\"}\u0027\n\n# Note: refresh tokens are one-time use, so this only works if the\n# legitimate client has not already consumed the token and if the attacker has\n# compromised your infrastructure to get access to this information\n```\n\n## Impact\n\n1. **Session Hijacking**: Anyone who obtains the token before it is consumed by the legitimate client can generate new access tokens, though the refresh token is one-time use and cannot be reused after consumption.\n\n2. **Leak Vectors**: URL query parameters are visible in owned infrastructure and integrated services:\n - Browser history (local access)\n - HTTP Referer headers (mitigated by modern browser default referrer policies; only sent to developer-integrated services)\n - Server access logs (owned infrastructure)\n - Proxy/CDN/WAF logs (owned infrastructure)\n\n3. **Affects All OAuth Providers**: Every OAuth provider flow (GitHub, Google, Apple, etc.) goes through the same callback handler.\n\n## Fix\n\nImplemented PKCE (Proof Key for Code Exchange) for the OAuth flow. With PKCE, the authorization code cannot be exchanged without the `code_verifier` that only the original client possesses, preventing token misuse even if the URL is logged.\n\nSee: https://docs.nhost.io/products/auth/pkce/\n\n## Resources\n\n- OWASP: Session Management - Token Transport: \"Session tokens should not be transported in the URL\"\n- RFC 6749 Section 10.3: \"Access tokens and refresh tokens MUST NOT be included in the redirect URI\"\n- CWE-598: Use of GET Request Method With Sensitive Query Strings\n- CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
"id": "GHSA-g2qj-prgh-4g9r",
"modified": "2026-04-06T23:25:15Z",
"published": "2026-04-01T23:36:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nhost/nhost/security/advisories/GHSA-g2qj-prgh-4g9r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34969"
},
{
"type": "WEB",
"url": "https://docs.nhost.io/products/auth/pkce"
},
{
"type": "PACKAGE",
"url": "https://github.com/nhost/nhost"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Nhost Leaks Refresh Tokens via URL Query Parameter in OAuth Provider Callback"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.