CVE-2024-47869: Gradio timing attack exposes analytics

CISO Take

Internet-exposed Gradio deployments running versions below 4.44.0 are vulnerable to a timing side-channel that allows an unauthenticated attacker to brute-force the analytics dashboard hash byte-by-byte. Upgrade to gradio >= 4.44.0 immediately; if patching is delayed, disable the analytics dashboard or restrict access to trusted networks. Real-world exploitation risk is low due to high attack complexity, but any public-facing ML demo or prototyping environment using Gradio should be prioritized.

What is the risk?

Low severity (CVSS 3.7) with high attack complexity — timing attacks against network services require hundreds to thousands of precise measurements and are highly sensitive to network jitter, making reliable exploitation difficult in practice. EPSS of 0.00158 confirms negligible exploitation probability in the wild. However, Gradio is extremely popular for ML prototyping and demos, and many deployments are internet-exposed with default configurations, which broadens the attack surface. Unauthorized access is limited to analytics data (usage statistics, interaction logs), not model weights or training data. Not in CISA KEV and no evidence of active exploitation.

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 →
Gradio	pip	< 4.44.0	`4.44.0`
43.0K OpenSSF 5.6 685 dependents Pushed 5d ago 26% patched ~110d to patch Full package profile →

How severe is it?

CVSS 3.1

3.7 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 20% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Advanced

What is the attack surface?

AV Network

AC High

PR None

UI None

S Unchanged

C Low

I None

A None

What should I do?

5 steps

PATCH

Upgrade to gradio >= 4.44.0 which implements constant-time hash comparison.
WORKAROUND (pre-patch): Manually patch the analytics_dashboard function to use Python's hmac.compare_digest() instead of standard equality comparison for hash values.
NETWORK CONTROL

Restrict access to the analytics dashboard endpoint to trusted IP ranges or internal networks only; do not expose it publicly.
DISABLE

If analytics dashboard is not needed, disable it entirely in Gradio configuration.
DETECTION

Monitor for anomalous high-volume repeated requests to the analytics dashboard endpoint with slight variations — this is characteristic of timing attack probing. Alert on >100 requests/minute from a single source to dashboard endpoints.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

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

How is it classified?

Auth Bypass Data Extraction Framework API AML.T0006 - Active Scanning AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.15 - Accuracy, Robustness and Cybersecurity

ISO 42001

A.6.2 - Information security in AI system development

NIST AI RMF

GOVERN 1.7 - Processes for decommissioning and oversight MANAGE 2.4 - Residual risks are managed

OWASP LLM Top 10

LLM09 - Overreliance

Frequently Asked Questions

What is CVE-2024-47869?

Internet-exposed Gradio deployments running versions below 4.44.0 are vulnerable to a timing side-channel that allows an unauthenticated attacker to brute-force the analytics dashboard hash byte-by-byte. Upgrade to gradio >= 4.44.0 immediately; if patching is delayed, disable the analytics dashboard or restrict access to trusted networks. Real-world exploitation risk is low due to high attack complexity, but any public-facing ML demo or prototyping environment using Gradio should be prioritized.

Is CVE-2024-47869 actively exploited?

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

How to fix CVE-2024-47869?

1. PATCH: Upgrade to gradio >= 4.44.0 which implements constant-time hash comparison. 2. WORKAROUND (pre-patch): Manually patch the `analytics_dashboard` function to use Python's `hmac.compare_digest()` instead of standard equality comparison for hash values. 3. NETWORK CONTROL: Restrict access to the analytics dashboard endpoint to trusted IP ranges or internal networks only; do not expose it publicly. 4. DISABLE: If analytics dashboard is not needed, disable it entirely in Gradio configuration. 5. DETECTION: Monitor for anomalous high-volume repeated requests to the analytics dashboard endpoint with slight variations — this is characteristic of timing attack probing. Alert on >100 requests/minute from a single source to dashboard endpoints.

What systems are affected by CVE-2024-47869?

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

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

CVE-2024-47869 has a CVSS v3.1 base score of 3.7 (LOW). The EPSS exploitation probability is 0.29%.

What is the AI security impact?

Affected AI Architectures

ML demo platformsmodel servingAI prototyping environments

MITRE ATLAS Techniques

AML.T0006 Active Scanning

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art.15

ISO 42001: A.6.2

NIST AI RMF: GOVERN 1.7, MANAGE 2.4

OWASP LLM Top 10: LLM09

What are the technical details?

Original Advisory

Gradio is an open-source Python package designed for quick prototyping. This vulnerability involves a **timing attack** in the way Gradio compares hashes for the `analytics_dashboard` function. Since the comparison is not done in constant time, an attacker could exploit this by measuring the response time of different requests to infer the correct hash byte-by-byte. This can lead to unauthorized access to the analytics dashboard, especially if the attacker can repeatedly query the system with different keys. Users are advised to upgrade to `gradio>4.44` to mitigate this issue. To mitigate the risk before applying the patch, developers can manually patch the `analytics_dashboard` dashboard to use a **constant-time comparison** function for comparing sensitive values, such as hashes. Alternatively, access to the analytics dashboard can be disabled.

Exploitation Scenario

An adversary identifies a public-facing Gradio instance (e.g., via Shodan, Hugging Face Spaces enumeration, or direct knowledge of an internal deployment) with the analytics dashboard enabled. They write a script that sends thousands of authentication attempts to the dashboard endpoint, varying the hash value one byte at a time and measuring response times using high-resolution timers. By collecting statistical timing data across many requests and accounting for network jitter, the attacker infers each byte of the correct hash sequentially — a classic timing oracle attack. After reconstructing the valid hash (likely requiring tens of thousands of requests over hours), the attacker gains unauthorized access to the analytics dashboard and exfiltrates usage telemetry, user interaction logs, and system metrics that reveal the AI application's behavior and usage patterns.

Weaknesses (CWE)

CWE-203 Observable Discrepancy Primary CWE-208 Observable Timing Discrepancy Primary CWE-203 Observable Discrepancy

CWE-203 — Observable Discrepancy: The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor.

[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
[Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

Source: MITRE CWE corpus.