Gradio: Mocked OAuth Login Exposes Server Credentials and Uses Hardcoded Session Secret

Summary

Gradio applications running outside of Hugging Face Spaces automatically enable "mocked" OAuth routes when OAuth components (e.g. gr.LoginButton) are used. When a user visits /login/huggingface, the server retrieves its own Hugging Face access token via huggingface_hub.get_token() and stores it in the visitor's session cookie. If the application is network-accessible, any remote attacker can trigger this flow to steal the server owner's HF token. The session cookie is signed with a hardcoded secret derived from the string "-v4", making the payload trivially decodable.

Affected Component

gradio/oauth.py — functions attach_oauth(), _add_mocked_oauth_routes(), and _get_mocked_oauth_info().

Root Cause Analysis

1. Real token injected into every visitor's session

When Gradio detects it is not running inside a Hugging Face Space (get_space() is None), it registers mocked OAuth routes via _add_mocked_oauth_routes() (line 44).

The function _get_mocked_oauth_info() (line 307) calls huggingface_hub.get_token() to retrieve the real HF access token configured on the host machine (via HF_TOKEN environment variable or huggingface-cli login). This token is stored in a dict that is then injected into the session of any visitor who hits /login/callback (line 183):

request.session["oauth_info"] = mocked_oauth_info

The mocked_oauth_info dict contains the real token at key access_token (line 329):

return {
    "access_token": token,  #