Critical Credential Leakage and Open Redirect in Gradio OAuth Flow

CVE-2026-27167 describes a critical security failure in gradio, a popular Python library for building machine learning demonstrations. The vulnerability specifically affects the OAuth authentication flow when the application is hosted in environments other than Hugging Face Spaces (e.g., local development, on-premise servers, or third-party clouds).

When running in these environments, Gradio defaults to a 'mocked' OAuth flow to simulate authentication without requiring a full provider configuration. However, this implementation contained a severe logic error: it retrieved the actual Hugging Face authentication token from the server's environment (specifically HF_TOKEN) and embedded it into the user's session cookie. Combined with a weak, predictable signing key for the session cookie, this allows remote attackers to recover the plaintext credentials.

Furthermore, the login endpoint failed to validate the _target_url parameter, enabling an Open Redirect (CWE-601). This allows attackers to craft URLs that appear to be legitimate authentication links but redirect victims to malicious domains after the mock login completes.

The vulnerability stems from three converging failures in gradio/oauth.py:

1. Insecure Default Credential Usage (CWE-522) The function _get_mocked_oauth_info was designed to provide dummy user data for the mocked login flow. Instead of returning static placeholder data, the implementation called huggingface_hub.get_token(). This function retrieves the active authentication token from the server's environment variables or local cache. Consequently, the server's identity credential was serialized into the access_token field of every user session.

2. Predictable Cryptographic Signing Key (CWE-321) Gradio uses signed cookies to store session state. The signing key is derived from the application's secret. In the mocked flow, if the developer did not explicitly set an OAUTH_CLIENT_SECRET, the application defaulted to a derived key that often resolved to the string "-v4" (or app_secret + "-v4" where app_secret was empty or predictable). This low-entropy secret allows attackers to easily forge or decrypt session cookies offline.

3. Unvalidated Redirect Target (CWE-601) The _redirect_to_target function accepted a _target_url query parameter and passed it directly to fastapi.responses.RedirectResponse. Lacking any validation or sanitization, the application would honor redirects to external schemas (e.g., https://evil.com), facilitating phishing attacks leveraged against the trusted domain of the Gradio app.

The patch introduced in version 6.6.0 addresses the vulnerability by replacing the dynamic token retrieval with a static string and enforcing strict URL parsing on redirects.

Credential Leakage Fix

In the vulnerable version, the code actively fetched the environment token:

# Vulnerable: gradio/oauth.py
def _get_mocked_oauth_info() -> dict:
    # DANGEROUS: Fetches the actual server token
    token = huggingface_hub.get_token()
    return {
        "access_token": token,
        "user": {"username": "user", "id": "1"}
    }

The patched version replaces this with a safe constant:

# Fixed: gradio/oauth.py
def _get_mocked_oauth_info() -> dict:
    # SAFE: Returns a static placeholder string
    return {
        "access_token": "mock-oauth-token-for-local-dev",
        "user": {"username": "user", "id": "1"}
    }

Open Redirect Fix

The redirection logic was updated to strip the domain and scheme, forcing all redirects to be relative to the application root:

# Fixed: gradio/oauth.py
import urllib.parse
 
def _redirect_to_target(request: Request, default_target: str = "/") -> RedirectResponse:
    target = request.query_params.get("_target_url", default_target)
    # PATCH: Parse the URL and reconstruct only the path and query
    parsed = urllib.parse.urlparse(target)
    safe_target = parsed.path or "/"
    if parsed.query:
        safe_target += "?" + parsed.query
    return RedirectResponse(safe_target)

An attacker can exploit this vulnerability without authentication if the Gradio server is accessible over the network. The attack chain proceeds as follows:

1. Initiate Login: The attacker sends a GET request to http://<target>/login/huggingface. The _target_url parameter is optional but can be used to test the Open Redirect simultaneously.
2. Capture Session: The server responds with a 307 Temporary Redirect (or similar) and sets a session cookie. This cookie contains the base64-encoded and signed session data.
3. Decrypt Session: Because the signing key in the mocked flow is often the trivial string "-v4", the attacker can use a tool like itsdangerous or a simple Python script to unsign the cookie without needing a brute-force attack.
4. Extract Token: The decoded session payload is a JSON object. The attacker reads the access_token field. In vulnerable versions, this field contains the server's live HF_TOKEN.
5. Pivot: The attacker uses the stolen HF_TOKEN to authenticate against the Hugging Face API, potentially accessing private repositories, modifying models, or poisoning datasets associated with the server owner's account.

The impact of this vulnerability is Critical due to the high value of the compromised credentials.

• Confidentiality (High): The leaked HF_TOKEN may belong to a user with administrative privileges or write access to high-value models and datasets. Exposure allows unauthorized access to intellectual property and sensitive training data.
• Integrity (High): With write access, an attacker could inject malicious code into machine learning models (model poisoning) or modify dataset contents, leading to supply chain attacks downstream.
• Availability (Low): While the primary risk is data theft, an attacker could delete private repositories, causing service disruption.

Likelihood: The exploitation difficulty is Low (AC:L) because the signing key is predictable by default in the affected configuration. The vector is Network (AV:N) and requires no privileges (PR:N).