CVE-2026-27167: Gradio Information Disclosure Vulnerability

CVE-2026-27167 Overview

CVE-2026-27167 is a credential exposure vulnerability in Gradio, an open-source Python package designed for quick prototyping of machine learning applications. Starting in version 4.16.0 and prior to version 6.6.0, Gradio applications running outside of Hugging Face Spaces automatically enable "mocked" OAuth routes when OAuth components (e.g., gr.LoginButton) are used. This flaw allows remote attackers to steal the server owner's Hugging Face access token through a trivially exploitable authentication flow.

Critical Impact

Remote attackers can steal server owner Hugging Face tokens from any network-accessible Gradio application using OAuth components, potentially compromising associated machine learning models, datasets, and organizational resources.

Affected Products

• Gradio versions 4.16.0 through 6.5.x
• Gradio applications using OAuth components (gr.LoginButton, etc.)
• Deployments running outside of Hugging Face Spaces environment

Discovery Timeline

• 2026-02-27 - CVE CVE-2026-27167 published to NVD
• 2026-03-05 - Last updated in NVD database

Technical Details for CVE-2026-27167

Vulnerability Analysis

This vulnerability stems from insecure credential handling in Gradio's OAuth implementation (CWE-522: Insufficiently Protected Credentials). When a Gradio application uses OAuth components like gr.LoginButton and runs outside the Hugging Face Spaces environment, the framework automatically enables "mocked" OAuth routes intended for development purposes. These mocked routes create a dangerous authentication flow that exposes the server owner's credentials.

When any visitor accesses the /login/huggingface endpoint, the server retrieves its own Hugging Face access token via the huggingface_hub.get_token() function and stores it directly in the visitor's session cookie. This means any remote attacker who can reach the application over the network can trigger this flow and receive the server owner's token.

Compounding the issue, the session cookie is signed using a hardcoded secret derived from the string "-v4", making the cookie payload trivially decodable by anyone with knowledge of this static secret. This allows attackers to easily extract the Hugging Face token from the stolen session cookie.

Root Cause

The root cause of this vulnerability is the automatic enablement of development-mode OAuth mocking in production environments combined with the use of a hardcoded cryptographic secret. The mocked OAuth flow was likely intended for local development and testing but was inadvertently activated on network-accessible deployments. The hardcoded secret "-v4" used for session cookie signing eliminates any cryptographic protection for the sensitive token data stored in the session.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by simply sending an HTTP request to the /login/huggingface endpoint on any vulnerable Gradio application that is network-accessible and uses OAuth components.

The exploitation flow involves:

1. The attacker identifies a network-accessible Gradio application using OAuth components
2. The attacker sends a request to the /login/huggingface endpoint
3. The server retrieves its own Hugging Face token via huggingface_hub.get_token()
4. The server stores this token in a session cookie and returns it to the attacker
5. The attacker decodes the session cookie using the known hardcoded secret derived from "-v4"
6. The attacker extracts the Hugging Face access token for unauthorized use

No proof-of-concept code has been published. For technical implementation details, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-27167

Indicators of Compromise

• Unexpected HTTP requests to /login/huggingface endpoints from external IP addresses
• Unusual activity on Hugging Face accounts associated with Gradio server tokens
• Session cookie extraction attempts or large numbers of authentication requests
• Unauthorized access to Hugging Face models, datasets, or spaces linked to compromised tokens

Detection Strategies

• Monitor web server access logs for requests to /login/huggingface from untrusted sources
• Implement alerting for abnormal authentication patterns on Gradio application endpoints
• Review Hugging Face account activity logs for unauthorized API calls or resource modifications
• Deploy network-level monitoring to detect reconnaissance against OAuth endpoints

Monitoring Recommendations

• Enable detailed access logging for all Gradio application endpoints
• Configure Hugging Face account audit logs and review them regularly for suspicious activity
• Implement rate limiting and anomaly detection on authentication-related endpoints
• Consider deploying a Web Application Firewall (WAF) to filter malicious requests to sensitive routes

How to Mitigate CVE-2026-27167

Immediate Actions Required

• Upgrade Gradio to version 6.6.0 or later immediately
• Rotate any Hugging Face tokens that may have been exposed on vulnerable deployments
• Audit Hugging Face account activity for signs of unauthorized access
• Review network access controls for Gradio applications to restrict exposure

Patch Information

The vulnerability is addressed in Gradio version 6.6.0, which disables the automatic mocked OAuth routes and implements proper secret management. Organizations should upgrade to this version or later as soon as possible. Detailed patch information is available in the GitHub Security Advisory for GHSA-h3h8-3v2v-rg7m.

Workarounds

• Restrict network access to Gradio applications using firewall rules or network segmentation
• Avoid using OAuth components (gr.LoginButton) in Gradio versions prior to 6.6.0
• Deploy vulnerable applications only within Hugging Face Spaces environment where mocked routes are not enabled
• Implement reverse proxy authentication to protect sensitive endpoints from external access

# Example: Restrict access to Gradio application using iptables
# Allow only internal network access to Gradio port (default 7860)
iptables -A INPUT -p tcp --dport 7860 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 7860 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 7860 -j DROP