Open Redirect in Gradio OAuth Flow Enables Phishing Attacks

Gradio is an open-source Python package widely used for creating and sharing machine learning applications, particularly within the Hugging Face ecosystem. The library provides built-in authentication mechanisms via OAuth to secure these applications. A vulnerability was discovered in how the library handles post-authentication and post-logout redirects.

The specific flaw is an Open Redirect (CWE-601) located in the _redirect_to_target function. This function is responsible for guiding the user's browser to a specific page after a login or logout action completes. By default, it accepts a target URL from the incoming request's query parameters.

Because the application fails to validate whether the destination URL resides within the application's own domain, an attacker can manipulate this parameter. This allows them to generate links that appear to originate from a trusted domain (e.g., myapp.hf.space) but actually redirect the victim to an attacker-controlled site immediately after interaction.

The root cause of this vulnerability is the direct, unsanitized usage of user-controlled input in an HTTP response header. The vulnerable logic resides in gradio/oauth.py within the _redirect_to_target helper function.

In the vulnerable versions, the function retrieves the _target_url query parameter from the FastAPI request object and passes it directly to the RedirectResponse constructor. The RedirectResponse class in Starlette/FastAPI sets the Location header to the provided string and issues a 302 Found status code.

The code does not check if the URL is absolute (containing a scheme and hostname) or relative. The lack of an allowlist or domain validation means that any valid URL string is accepted. If an attacker supplies https://evil.com, the server explicitly instructs the browser to navigate there, treating the external domain as a valid destination for the application flow.

The remediation involves parsing the input URL and stripping out the scheme (protocol) and network location (hostname), effectively forcing all redirects to be relative to the application's root.

Vulnerable Code (gradio/oauth.py):

def _redirect_to_target(
    request: fastapi.Request, default_target: str = "/"
) -> RedirectResponse:
    # VULNERABLE: Takes the parameter directly from the request
    target = request.query_params.get("_target_url", default_target)
    # Returns a 302 Redirect to the exact string provided
    return RedirectResponse(target)

Patched Code (Fixed in v6.6.0):

import urllib.parse
 
def _redirect_to_target(
    request: fastapi.Request, default_target: str = "/"
) -> RedirectResponse:
    target = request.query_params.get("_target_url", default_target)
    
    # PATCH: Parse the URL to inspect its components
    parsed = urllib.parse.urlparse(target)
    
    # Construct a 'safe' target using only the path, query, and fragment.
    # This discards 'scheme' (http/https) and 'netloc' (domain.com).
    safe_target = parsed.path or "/"
    if parsed.query:
        safe_target += "?" + parsed.query
    if parsed.fragment:
        safe_target += "#" + parsed.fragment
        
    return RedirectResponse(safe_target)

This robust fix ensures that even if an attacker supplies https://evil.com/login, urllib.parse separates the components. The logic then reconstructs the URL using only the path /login, keeping the user on the legitimate site.

Exploitation of CVE-2026-28415 requires user interaction but is trivial to execute. The attacker needs to craft a URL pointing to a vulnerable Gradio instance's logout or login callback endpoints.

Attack Scenario:

1. Preparation: The attacker sets up a phishing page at https://evil-login.com that mimics the look and feel of the target Gradio app or Hugging Face login.
2. Delivery: The attacker sends a phishing email or message containing a link: https://trusted-app.hf.space/logout?_target_url=https://evil-login.com.
3. Execution: The victim clicks the link. They see the domain trusted-app.hf.space and trust it. The application processes the logout request and immediately responds with Location: https://evil-login.com.
4. Compromise: The browser automatically follows the redirect. The user, believing they simply logged out, may see a fake "Session Expired, Please Login Again" prompt on the attacker's site and enter their credentials.

This vector is particularly effective because security training often emphasizes checking the domain of the initial link. Since the initial link is legitimate, it bypasses basic user scrutiny.

While Open Redirect vulnerabilities do not directly allow for Remote Code Execution (RCE) or database access, they are a critical enabler for sophisticated social engineering attacks.

Trust Exploitation: The primary impact is the weaponization of the organization's reputation. Security controls like email filters often allowlist known domains (e.g., *.hf.space). An open redirect allows malicious payloads to ride on these allowlisted domains.

OAuth Token Leakage: In some OAuth misconfigurations, if the redirect occurs during the authorization phase and the attacker controls the redirect URI, it may be possible to leak authorization codes or access tokens via the Referer header or direct URL parameters, although the patch here specifically addresses the destination after the flow completes.

CVSS Context: The assigned score of 4.3 (Medium) reflects that while the technical impact on the server is nil (Integrity: Low, Confidentiality: None), the requirement for user interaction and the limitation to client-side redirection constrains the severity.