CVE-2024-1727: Gradio CSRF enables disk exhaustion

CISO Take

Teams running Gradio locally for ML demos or model prototyping are exposed to denial-of-service via disk exhaustion if a researcher visits a malicious webpage. Patch to the fixed commit immediately and restrict Gradio server binding to localhost-only with no external network exposure. Risk is highest in shared ML dev environments where disk exhaustion can disrupt CI/CD pipelines and active training jobs.

What is the risk?

Medium risk for ML development environments. The CSRF exploit is trivial—no AI knowledge required—but impact is bounded to local or intranet-accessible Gradio instances. In shared ML infrastructure such as JupyterHub or team dev servers, the blast radius expands significantly as disk exhaustion can halt multiple users and running workloads simultaneously. No active exploitation reported and no CISA KEV listing, but the attack surface is broad given Gradio's widespread adoption in the ML community.

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

0.4%

chance of exploitation in 30 days

Higher than 27% 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)

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

Patch: update to commit 84802ee6a4806c25287344dce581f9548a99834a or the corresponding patched Gradio release.
Restrict binding: launch Gradio with --server_name 127.0.0.1 to prevent any network access beyond localhost.
Add upload rate limiting and maximum file size caps at the reverse proxy or application level.
Monitor disk usage on ML dev servers with alerting on anomalous rapid consumption in upload or temp directories.
Audit firewall rules to ensure no Gradio ports (default 7860) are inadvertently exposed. Detection: watch for high-frequency POST requests to /upload endpoints from unexpected origins.

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?

DoS Auth Bypass Framework AML.T0029 - Denial of AI Service AML.T0049 - Exploit Public-Facing Application AML.T0078 - Drive-by Compromise

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

8.4 - AI system security

NIST AI RMF

MS-2.5 - Risk Response

OWASP LLM Top 10

LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2024-1727?

Teams running Gradio locally for ML demos or model prototyping are exposed to denial-of-service via disk exhaustion if a researcher visits a malicious webpage. Patch to the fixed commit immediately and restrict Gradio server binding to localhost-only with no external network exposure. Risk is highest in shared ML dev environments where disk exhaustion can disrupt CI/CD pipelines and active training jobs.

Is CVE-2024-1727 actively exploited?

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

How to fix CVE-2024-1727?

1. Patch: update to commit 84802ee6a4806c25287344dce581f9548a99834a or the corresponding patched Gradio release. 2. Restrict binding: launch Gradio with --server_name 127.0.0.1 to prevent any network access beyond localhost. 3. Add upload rate limiting and maximum file size caps at the reverse proxy or application level. 4. Monitor disk usage on ML dev servers with alerting on anomalous rapid consumption in upload or temp directories. 5. Audit firewall rules to ensure no Gradio ports (default 7860) are inadvertently exposed. Detection: watch for high-frequency POST requests to /upload endpoints from unexpected origins.

What systems are affected by CVE-2024-1727?

This vulnerability affects the following AI/ML architecture patterns: ML development environments, model demo/prototyping, local model serving.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

ML development environmentsmodel demo/prototypinglocal model serving

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0049 Exploit Public-Facing Application

AML.T0078 Drive-by Compromise

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: 8.4

NIST AI RMF: MS-2.5

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

A Cross-Site Request Forgery (CSRF) vulnerability in gradio-app/gradio allows attackers to upload multiple large files to a victim's system if they are running Gradio locally. By crafting a malicious HTML page that triggers an unauthorized file upload to the victim's server, an attacker can deplete the system's disk space, potentially leading to a denial of service. This issue affects the file upload functionality as implemented in gradio/routes.py.

Exploitation Scenario

An attacker hosts a malicious HTML page containing JavaScript that silently fires multiple large file upload POST requests to http://localhost:7860/upload—Gradio's default endpoint—the moment a victim visits the page. No authentication is required due to the absent CSRF token validation. The victim, likely an ML engineer with a local Gradio demo running, has their disk progressively filled until the system becomes unresponsive, interrupting active model training, corrupting in-progress experiments, or crashing shared infrastructure. The entire attack is invisible to the victim and requires only one page visit.

Weaknesses (CWE)

CWE-352 Cross-Site Request Forgery (CSRF)

CWE-352 — Cross-Site Request Forgery (CSRF): The web application does not, or cannot, sufficiently verify whether a request was intentionally provided by the user who sent the request, which could have originated from an unauthorized actor.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330] Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]
[Implementation] Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.

Source: MITRE CWE corpus.