CVE-2026-59806: Gradio SSRF — HIGH

CISO Take

Gradio before 6.20.0 fails to validate URLs passed to the file_fetch() function behind the /gradio_api/file= endpoint, letting an attacker supply an internal or cloud-metadata URL that the server fetches on the victim's behalf, or redirect users to an arbitrary attacker-controlled site. Because Gradio apps are routinely deployed on cloud VMs and container platforms (AWS EC2, GCP, Hugging Face Spaces) to expose ML demos and internal tooling, a successful SSRF against the instance metadata service can hand an attacker live IAM role credentials — effectively a path from a UI vulnerability to full cloud account compromise. The bug requires user interaction (CVSS UI:R) and no authentication (PR:N), so the realistic path is a crafted link sent to a developer or user with access to the Gradio instance; EPSS sits at 0.25% absolute (84th percentile) and there's no KEV listing or public exploit yet, so this is not under active exploitation but the impact ceiling is high given how many AI demos run with attached cloud roles. Patch to Gradio 6.20.0 immediately; if you can't patch yet, block outbound access from the Gradio host to 169.254.169.254 (and equivalent GCP/Azure metadata IPs) at the network/firewall layer and enforce IMDSv2-only on any EC2 instances hosting Gradio. Detection: monitor outbound requests from Gradio hosts to link-local metadata ranges and flag any file_fetch requests targeting non-allowlisted hosts.

Sources: NVD EPSS GitHub Advisory ATLAS vulncheck.com

What is the risk?

High severity (CVSS 7.4) driven by a confidentiality-impacting SSRF chained with an open redirect (CWE-918/CWE-601). Exploitability is moderate: no authentication required and low attack complexity, but successful exploitation requires the victim to interact with a crafted link/request (UI:R), and the impact ceiling depends entirely on network exposure — a Gradio instance with no route to a cloud metadata service or internal admin endpoints has materially lower real-world risk than one running on EC2/GCP with an attached IAM role. EPSS (0.25% absolute, 84th percentile) and the absence of a CISA KEV listing, public exploit, or Nuclei template indicate no evidence of active exploitation today, but the vulnerability class (metadata-service SSRF) is a well-understood, high-payoff technique that scanners and opportunistic attackers pick up quickly once public PoCs land — this warrants prompt patching rather than a wait-and-see posture.

How does the attack unfold?

Initial Access

Attacker crafts a malicious link embedding a FileData payload targeting the /gradio_api/file= endpoint and sends it to a user with access to the Gradio instance.

AML.T0011.003

SSRF Exploitation

The victim's interaction triggers file_fetch() to make an unvalidated server-side request to an attacker-chosen internal URL, exploiting the public-facing Gradio application.

AML.T0049

Credential Theft

The server-side request reaches the cloud instance metadata service and retrieves the EC2 IAM role's temporary credentials, which are exposed to the attacker.

AML.T0106

Cloud Impact

Attacker reuses the stolen IAM credentials to access other cloud resources tied to the compromised role, escalating from a UI bug to broader cloud account compromise.

AML.T0055

Initial Access

Attacker crafts a malicious link embedding a FileData payload targeting the /gradio_api/file= endpoint and sends it to a user with access to the Gradio instance.

AML.T0011.003

SSRF Exploitation

The victim's interaction triggers file_fetch() to make an unvalidated server-side request to an attacker-chosen internal URL, exploiting the public-facing Gradio application.

AML.T0049

Credential Theft

The server-side request reaches the cloud instance metadata service and retrieves the EC2 IAM role's temporary credentials, which are exposed to the attacker.

AML.T0106

Cloud Impact

Attacker reuses the stolen IAM credentials to access other cloud resources tied to the compromised role, escalating from a UI bug to broader cloud account compromise.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Gradio	pip	—	No patch
43.4K OpenSSF 5.3 682 dependents Pushed yesterday 28% patched ~105d to patch Full package profile →

Do you use Gradio? You're affected.

How severe is it?

CVSS 3.1

7.4 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 16% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI Required

S Changed

C High

I None

A None

What should I do?

1 step

1) Upgrade Gradio to 6.20.0 or later immediately — the fix is a straightforward version bump (see gradio-app/gradio PR #13596 and the 6.20.0 release notes). 2) If immediate upgrade isn't possible, restrict outbound network access from any host running Gradio so it cannot reach 169.254.169.254 (AWS/GCP/Azure metadata IP) or other internal-only services, via security group / firewall / egress proxy rules. 3) Enforce IMDSv2 (session-token-required) on EC2 instances hosting Gradio so a naive SSRF GET request cannot retrieve credentials even if the endpoint is reachable. 4) Rotate any IAM role credentials attached to hosts that were running vulnerable Gradio versions with metadata-service reachability, as a precaution. 5) Detection: alert on outbound requests from Gradio processes to link-local (169.254.0.0/16) or RFC1918 ranges outside expected service dependencies, and monitor /gradio_api/file= access logs for URLs pointing to internal hosts or metadata IPs.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data Leakage Social Engineering Framework API AML.T0011.003 - Malicious Link AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials AML.T0075 - Cloud Service Discovery AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system security

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluation

Frequently Asked Questions

What is CVE-2026-59806?

Gradio before 6.20.0 fails to validate URLs passed to the file_fetch() function behind the /gradio_api/file= endpoint, letting an attacker supply an internal or cloud-metadata URL that the server fetches on the victim's behalf, or redirect users to an arbitrary attacker-controlled site. Because Gradio apps are routinely deployed on cloud VMs and container platforms (AWS EC2, GCP, Hugging Face Spaces) to expose ML demos and internal tooling, a successful SSRF against the instance metadata service can hand an attacker live IAM role credentials — effectively a path from a UI vulnerability to full cloud account compromise. The bug requires user interaction (CVSS UI:R) and no authentication (PR:N), so the realistic path is a crafted link sent to a developer or user with access to the Gradio instance; EPSS sits at 0.25% absolute (84th percentile) and there's no KEV listing or public exploit yet, so this is not under active exploitation but the impact ceiling is high given how many AI demos run with attached cloud roles. Patch to Gradio 6.20.0 immediately; if you can't patch yet, block outbound access from the Gradio host to 169.254.169.254 (and equivalent GCP/Azure metadata IPs) at the network/firewall layer and enforce IMDSv2-only on any EC2 instances hosting Gradio. Detection: monitor outbound requests from Gradio hosts to link-local metadata ranges and flag any file_fetch requests targeting non-allowlisted hosts.

Is CVE-2026-59806 actively exploited?

No confirmed active exploitation of CVE-2026-59806 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59806?

1) Upgrade Gradio to 6.20.0 or later immediately — the fix is a straightforward version bump (see gradio-app/gradio PR #13596 and the 6.20.0 release notes). 2) If immediate upgrade isn't possible, restrict outbound network access from any host running Gradio so it cannot reach 169.254.169.254 (AWS/GCP/Azure metadata IP) or other internal-only services, via security group / firewall / egress proxy rules. 3) Enforce IMDSv2 (session-token-required) on EC2 instances hosting Gradio so a naive SSRF GET request cannot retrieve credentials even if the endpoint is reachable. 4) Rotate any IAM role credentials attached to hosts that were running vulnerable Gradio versions with metadata-service reachability, as a precaution. 5) Detection: alert on outbound requests from Gradio processes to link-local (169.254.0.0/16) or RFC1918 ranges outside expected service dependencies, and monitor /gradio_api/file= access logs for URLs pointing to internal hosts or metadata IPs.

What systems are affected by CVE-2026-59806?

This vulnerability affects the following AI/ML architecture patterns: model serving, AI/ML demo UIs, agent frameworks.

What is the CVSS score for CVE-2026-59806?

CVE-2026-59806 has a CVSS v3.1 base score of 7.4 (HIGH). The EPSS exploitation probability is 0.25%.

What is the AI security impact?

Affected AI Architectures

model servingAI/ML demo UIsagent frameworks

MITRE ATLAS Techniques

AML.T0011.003 Malicious Link

AML.T0049 Exploit Public-Facing Application

AML.T0055 Unsecured Credentials

AML.T0075 Cloud Service Discovery

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

What are the technical details?

Original Advisory

Gradio before 6.20.0 contains an open redirect and server-side request forgery vulnerability that allows attackers to redirect users to arbitrary URLs or perform client-side SSRF by supplying unvalidated HTTP/HTTPS URLs to the file_fetch() function in the /gradio_api/file= endpoint. Attackers can craft a malicious FileData response targeting internal endpoints such as cloud metadata services to retrieve sensitive credentials including EC2 IAM role credentials.

Exploitation Scenario

An attacker builds a malicious link embedding a crafted FileData payload that targets the Gradio instance's own /gradio_api/file= endpoint with a URL pointing at the AWS instance metadata service (http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>). The attacker sends this link to a developer, demo user, or automated bot with access to the Gradio app (e.g., via a shared demo, support ticket, or phishing email framed as a bug report). When the link is opened, the Gradio server-side file_fetch() logic requests the attacker-supplied URL without validating that it stays within an allowed origin, retrieves the IAM role's temporary credentials from the metadata service, and — depending on how the response is rendered or reflected — exposes them to the attacker. The attacker then uses those short-lived but often broadly-scoped credentials to enumerate and access other cloud resources (S3 buckets, other EC2 instances, secrets managers) tied to the same IAM role, escalating from a UI-layer bug to a cloud account compromise.

Weaknesses (CWE)

CWE-601 URL Redirection to Untrusted Site ('Open Redirect') Primary CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-601 URL Redirection to Untrusted Site ('Open Redirect') CWE-918 Server-Side Request Forgery (SSRF)

CWE-601 — URL Redirection to Untrusted Site ('Open Redirect'): The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Source: MITRE CWE corpus.