CVE-2026-27167

What it actually does

Gradio versions 4.16.0 through versions before 6.6.0 can expose the server-side Hugging Face access token when an application runs outside Hugging Face Spaces and uses OAuth UI components such as `gr.LoginButton`. In that configuration, Gradio automatically enables mocked OAuth routes. A remote unauthenticated requester can access `/login/huggingface`, causing the server to call `huggingface_hub.get_token()` and place the server owner's Hugging Face token into the requester’s session cookie. The cookie is signed with a hardcoded secret derived from `"-v4"`, so the attacker can decode or validate the session payload and recover the token. The direct impact is credential disclosure rather than code execution; downstream impact depends on the permissions associated with the exposed Hugging Face token.

Why it matters to the business

A network-exposed Gradio application using affected OAuth components may leak the application owner’s Hugging Face token to anyone who can reach the login route. If that token has access to private models, datasets, organizations, or write permissions, an attacker could read confidential assets, alter hosted content, poison models or datasets, disrupt ML workflows, or use the token for unauthorized API activity. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, but the remediation should still be prioritized for externally reachable Gradio apps because exploitation requires no account and can directly expose reusable credentials.

How an attack unfolds

An attacker first identifies a network-accessible Gradio application that is running an affected version and includes Hugging Face OAuth-related components. The attacker sends a request to the mocked OAuth login endpoint, typically `/login/huggingface`. Instead of requiring a legitimate Hugging Face OAuth exchange, the vulnerable Gradio server retrieves its own local Hugging Face token using `huggingface_hub.get_token()` and serializes that token into the HTTP session cookie returned to the requester. Because the session cookie signing secret is hardcoded and publicly derivable from `"-v4"`, the attacker can decode the cookie payload and extract the Hugging Face token. The attacker can then use the token against Hugging Face APIs, Git operations, or model and dataset endpoints according to the token’s scope.

How to fix it

Upgrade Gradio to version 6.6.0 or later. For source-based deployments, update to a fixed commit at or after `89841593255f57cbb19da099b6e753110b1b99af`. Prioritize externally reachable Gradio applications and any deployment using OAuth components such as `gr.LoginButton`. If immediate upgrade is not possible, remove or disable Hugging Face OAuth components, block external access to `/login/huggingface`, place the application behind authentication or network allowlisting, and avoid running Gradio with a privileged Hugging Face token present in the runtime environment. Rotate any Hugging Face token that may have been exposed, especially tokens with organization, private repository, write, admin, model, dataset, or Space permissions. After rotation, invalidate old credentials and review Hugging Face account and organization activity for unauthorized access.

How to confirm the fix worked

Confirm the installed Gradio version is 6.6.0 or later, or that the deployed source includes commit `89841593255f57cbb19da099b6e753110b1b99af` or a later fix. Test a non-production or authorized instance by requesting `/login/huggingface` without authentication and verifying that the server does not place any Hugging Face token or token-like value in a returned session cookie. Review dependency lockfiles, container images, Python environments, and build artifacts for `gradio` versions from 4.16.0 through versions before 6.6.0. Confirm that externally reachable routes no longer expose mocked OAuth behavior and that old Hugging Face tokens have been rotated. Validate compensating controls by ensuring direct requests to `/login/huggingface` are denied, redirected to a real authentication flow, or unavailable where OAuth is not intentionally used.

Typical attack path

1. Discover an internet-accessible or internally reachable Gradio application.
2. Determine that the application exposes Hugging Face OAuth functionality or test for the mocked OAuth route.
3. Send an unauthenticated request to `/login/huggingface`.
4. Capture the HTTP response containing the session cookie.
5. Decode or verify the cookie using the known hardcoded signing secret derived from `"-v4"`.
6. Extract the embedded Hugging Face access token from the cookie payload.
7. Use the token to access or modify Hugging Face resources allowed by the token’s permissions.
8. Optionally pivot to related repositories, models, datasets, Spaces, or organization resources accessible with the token.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs, reverse proxy logs, load balancer logs, WAF logs, and application logs for requests to `/login/huggingface` on affected Gradio services. Focus on unauthenticated requests, external source IPs, scanner-like user agents, direct requests without normal application navigation, repeated probing, and responses that set a session cookie. Correlate any suspicious requests with Hugging Face account, organization, API, Git, model, dataset, and Space activity shortly afterward. Look for new or unexpected repository clones, pushes, model or dataset downloads, file modifications, Space deployments, token-authenticated API calls, permission changes, or access from unfamiliar IP addresses. On affected hosts, review process environments, secret stores, container definitions, and runtime configuration to identify which Hugging Face token could have been exposed, then compare its last-used timestamps and audit history. Because the credential is returned to the attacker in an HTTP cookie, endpoint forensic artifacts may be minimal unless web response headers, proxy telemetry, or full packet capture were retained.

• /login/huggingface
• GET /login/huggingface
• POST /login/huggingface
• "/login/huggingface" 200
• "/login/huggingface" 302
• Set-Cookie: session=
• huggingface
• gr.LoginButton
• gradio==4.16.0
• gradio==4.17.0
• gradio==4.18.0
• gradio==4.19.0
• gradio==4.20.0
• gradio==4.21.0
• gradio==4.22.0
• gradio==4.23.0
• gradio==4.24.0
• gradio==4.25.0
• gradio==4.26.0
• gradio==4.27.0
• gradio==4.28.0
• gradio==4.29.0
• gradio==4.30.0
• gradio==4.31.0
• gradio==4.32.0
• gradio==4.33.0
• gradio==4.34.0
• gradio==4.35.0
• gradio==4.36.0
• gradio==4.37.0
• gradio==4.38.0
• gradio==4.39.0
• gradio==4.40.0
• gradio==4.41.0
• gradio==4.42.0
• gradio==4.43.0
• gradio==4.44.0
• gradio==5.
• hf_

What your security team should do

• Inventory Gradio applications and identify deployments running versions 4.16.0 through before 6.6.0, especially those exposed to the internet or broad internal networks.
• Upgrade affected deployments to Gradio 6.6.0 or later, or rebuild from a source version containing commit `89841593255f57cbb19da099b6e753110b1b99af` or later.
• Immediately rotate Hugging Face tokens present on affected servers, prioritizing tokens with write, organization, private repository, dataset, model, or Space permissions.
• Search web access logs for unauthenticated or unusual requests to `/login/huggingface`, especially from external IP addresses, scanners, or clients with no normal user activity.
• Review Hugging Face audit logs, token usage, repository events, model and dataset changes, API activity, and Git access around any suspicious login-route requests.
• If upgrade is delayed, block `/login/huggingface`, remove OAuth components, restrict network exposure, and run Gradio services with least-privilege or no Hugging Face token where possible.
• Add dependency scanning or software composition analysis rules to flag affected Gradio versions in applications, notebooks, containers, and ML demo services.