CVE-2024-1183: Gradio SSRF enables internal

CISO Take

Gradio deployments used for ML model demos and inference UIs are vulnerable to unauthenticated SSRF, allowing attackers to map internal network topology by manipulating a single GET parameter. ML environments typically have privileged internal network access to databases, model servers, and cloud metadata endpoints — making this recon capability particularly dangerous. Patch immediately to the fixed commit and implement egress controls to prevent Gradio processes from reaching internal RFC 1918 address ranges.

What is the risk?

HIGH risk for organizations with internet-exposed Gradio instances. The exploit is trivial — no authentication, no special knowledge, just GET request manipulation — and ML environments typically run with broad internal network access. No CVSS score is assigned but exploitability is near-certain and impact includes full internal service enumeration. Cloud-deployed ML stacks expose additional risk via metadata endpoint access (169.254.169.254), potentially leading to credential theft and privilege escalation beyond initial recon.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Gradio	pip	—	No patch
43.0K OpenSSF 5.6 685 dependents Pushed 5d ago 26% patched ~110d to patch Full package profile →

Do you use Gradio? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

1.8%

chance of exploitation in 30 days

Higher than 75% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

○ Nuclei detection template available

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

What should I do?

5 steps

Apply the patch from commit 2ad3d9e7ec6c8eeea59774265b44f11df7394bb4 or upgrade to a patched Gradio release.
If immediate patching is blocked, restrict Gradio to authenticated-only access and place it behind a WAF with SSRF rules.
Implement egress filtering to block Gradio processes from initiating connections to RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata endpoints.
Audit firewall rules to ensure Gradio hosts are network-segmented from production model infrastructure and databases.
Monitor application logs for anomalous GET requests with IP addresses or internal hostnames in the file parameter.

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 Extraction Privacy Violation Framework Inference AML.T0006 - Active Scanning AML.T0049 - Exploit Public-Facing Application AML.T0075 - Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.9.1 - Security of AI systems

NIST AI RMF

MANAGE 2.4 - Residual risks from AI system operation and use

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2024-1183?

Gradio deployments used for ML model demos and inference UIs are vulnerable to unauthenticated SSRF, allowing attackers to map internal network topology by manipulating a single GET parameter. ML environments typically have privileged internal network access to databases, model servers, and cloud metadata endpoints — making this recon capability particularly dangerous. Patch immediately to the fixed commit and implement egress controls to prevent Gradio processes from reaching internal RFC 1918 address ranges.

Is CVE-2024-1183 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2024-1183, increasing the risk of exploitation.

How to fix CVE-2024-1183?

1. Apply the patch from commit 2ad3d9e7ec6c8eeea59774265b44f11df7394bb4 or upgrade to a patched Gradio release. 2. If immediate patching is blocked, restrict Gradio to authenticated-only access and place it behind a WAF with SSRF rules. 3. Implement egress filtering to block Gradio processes from initiating connections to RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata endpoints. 4. Audit firewall rules to ensure Gradio hosts are network-segmented from production model infrastructure and databases. 5. Monitor application logs for anomalous GET requests with IP addresses or internal hostnames in the file parameter.

What systems are affected by CVE-2024-1183?

This vulnerability affects the following AI/ML architecture patterns: model serving, ML demo infrastructure, AI development environments, internal ML APIs, Kubernetes ML clusters.

What is the CVSS score for CVE-2024-1183?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

model servingML demo infrastructureAI development environmentsinternal ML APIsKubernetes ML clusters

MITRE ATLAS Techniques

AML.T0006 Active Scanning

AML.T0049 Exploit Public-Facing Application

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.9.1

NIST AI RMF: MANAGE 2.4

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

An SSRF (Server-Side Request Forgery) vulnerability exists in the gradio-app/gradio repository, allowing attackers to scan and identify open ports within an internal network. By manipulating the 'file' parameter in a GET request, an attacker can discern the status of internal ports based on the presence of a 'Location' header or a 'File not allowed' error in the response.

Exploitation Scenario

An attacker targeting an ML team sends crafted GET requests to a public-facing Gradio demo (e.g., /file=http://192.168.1.100:6379). By observing whether the response contains a Location redirect header (port open) versus a 'File not allowed' error (port closed), the attacker iterates across internal IP ranges and common ML service ports — Redis (6379), MLflow (5000), Jupyter (8888), Kubeflow (8080), internal model APIs. Within minutes they build a complete internal service map. From there, unauthenticated services (common in internal ML tooling) become direct targets for follow-on exploitation.

Weaknesses (CWE)

CWE-601 URL Redirection to Untrusted Site ('Open Redirect')

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.