CVE-2026-10783: Gradio weak hash exposes audio cache

Q: Is CVE-2026-10783 actively exploited?

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

Q: How to fix CVE-2026-10783?

1. Upgrade Gradio to the first release after 6.14.0 that includes patch #13394 (track gradio-app/gradio releases). 2. If immediate upgrade is not feasible, restrict filesystem permissions on the Gradio audio cache directory to the process owner only (chmod 700 on the cache path). 3. Audit shared Gradio deployments to confirm no multi-tenant processes access the same filesystem context. 4. In Kubernetes or container environments, ensure each user's Gradio instance runs in an isolated pod with ephemeral, non-shared storage volumes. 5. Enable host-based file access monitoring on audio cache directories to detect unexpected cross-user reads. 6. For deployments processing sensitive audio data, consider disabling audio caching entirely as a temporary workaround pending patch deployment.

Q: What systems are affected by CVE-2026-10783?

This vulnerability affects the following AI/ML architecture patterns: ML demo deployments, model serving, audio processing pipelines, shared ML development environments.

Q: What is the CVSS score for CVE-2026-10783?

CVE-2026-10783 has a CVSS v3.1 base score of 2.5 (LOW). The EPSS exploitation probability is 0.11%.

CISO Take

Gradio 6.14.0 uses a cryptographically weak hashing algorithm (CWE-327/CWE-328) to generate cache keys for audio files processed through `save_audio_to_cache`, making those file paths potentially predictable or collision-prone. Exploitation is constrained to local access with high complexity, but shared Gradio deployments—common in enterprise ML prototyping, internal AI demo environments, and shared data science workstations—create a meaningful exposure surface where co-located low-privilege users could infer or brute-force cache paths to read other users' audio submissions. There is no KEV listing and CVSS scores low at 2.5, though the CVE description notes the exploit has been publicly released. Organizations running shared Gradio 6.14.0 instances should apply patch #13394, and where immediate upgrade is not feasible, restrict filesystem access to the audio cache directory to the Gradio process owner only.

Sources: NVD ATLAS

What is the risk?

Low overall risk due to mandatory local access, high attack complexity, and limited confidentiality scope. The principal risk surface is shared multi-user environments such as JupyterHub clusters, shared ML development servers, or containerized Gradio deployments with multiple tenant processes sharing a filesystem. In those scenarios, a malicious insider or compromised local account could exploit weak cache key predictability to access audio files submitted by other users. The absence of any integrity or availability impact further limits blast radius. Single-user or isolated deployments are not meaningfully exposed.

How does the attack unfold?

Local Access

Attacker obtains a low-privilege local account on a shared server running Gradio 6.14.0, such as a shared ML development workstation or multi-user JupyterHub node.

AML.T0012

Hash Reverse Engineering

Attacker analyzes the weak hash algorithm used in `save_audio_to_cache` via the publicly disclosed patch (#13394) to understand its predictability or collision properties.

AML.T0001

Cache Path Enumeration

Attacker computes expected cache file paths for audio submissions from co-located users by exploiting hash predictability or iterating the collision space.

AML.T0037

Data Exfiltration

Attacker reads and exfiltrates cached audio files belonging to other users, exposing voice recordings, proprietary audio inputs, or sensitive inference data.

AML.T0025

Local Access

Attacker obtains a low-privilege local account on a shared server running Gradio 6.14.0, such as a shared ML development workstation or multi-user JupyterHub node.

AML.T0012

Hash Reverse Engineering

Attacker analyzes the weak hash algorithm used in `save_audio_to_cache` via the publicly disclosed patch (#13394) to understand its predictability or collision properties.

AML.T0001

Cache Path Enumeration

Attacker computes expected cache file paths for audio submissions from co-located users by exploiting hash predictability or iterating the collision space.

AML.T0037

Data Exfiltration

Attacker reads and exfiltrates cached audio files belonging to other users, exposing voice recordings, proprietary audio inputs, or sensitive inference data.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Gradio	pip	< 6.15.1	`6.15.1`
43.3K OpenSSF 5.7 669 dependents Pushed 6d ago 28% patched ~105d to patch Full package profile →

Do you use Gradio? You're affected.

How severe is it?

CVSS 3.1

2.5 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 1% 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 Local

AC High

PR Low

UI None

S Unchanged

C Low

I None

A None

What should I do?

6 steps

Upgrade Gradio to the first release after 6.14.0 that includes patch #13394 (track gradio-app/gradio releases).
If immediate upgrade is not feasible, restrict filesystem permissions on the Gradio audio cache directory to the process owner only (chmod 700 on the cache path).
Audit shared Gradio deployments to confirm no multi-tenant processes access the same filesystem context.
In Kubernetes or container environments, ensure each user's Gradio instance runs in an isolated pod with ephemeral, non-shared storage volumes.
Enable host-based file access monitoring on audio cache directories to detect unexpected cross-user reads.
For deployments processing sensitive audio data, consider disabling audio caching entirely as a temporary workaround pending patch deployment.

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.T0025 - Exfiltration via Cyber Means AML.T0035 - AI Artifact Collection AML.T0037 - Data from Local System

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.9.4 - AI system security controls

NIST AI RMF

PROTECT-2.2 - AI system data protection

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-10783?

Gradio 6.14.0 uses a cryptographically weak hashing algorithm (CWE-327/CWE-328) to generate cache keys for audio files processed through `save_audio_to_cache`, making those file paths potentially predictable or collision-prone. Exploitation is constrained to local access with high complexity, but shared Gradio deployments—common in enterprise ML prototyping, internal AI demo environments, and shared data science workstations—create a meaningful exposure surface where co-located low-privilege users could infer or brute-force cache paths to read other users' audio submissions. There is no KEV listing and CVSS scores low at 2.5, though the CVE description notes the exploit has been publicly released. Organizations running shared Gradio 6.14.0 instances should apply patch #13394, and where immediate upgrade is not feasible, restrict filesystem access to the audio cache directory to the Gradio process owner only.

Is CVE-2026-10783 actively exploited?

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

How to fix CVE-2026-10783?

1. Upgrade Gradio to the first release after 6.14.0 that includes patch #13394 (track gradio-app/gradio releases). 2. If immediate upgrade is not feasible, restrict filesystem permissions on the Gradio audio cache directory to the process owner only (chmod 700 on the cache path). 3. Audit shared Gradio deployments to confirm no multi-tenant processes access the same filesystem context. 4. In Kubernetes or container environments, ensure each user's Gradio instance runs in an isolated pod with ephemeral, non-shared storage volumes. 5. Enable host-based file access monitoring on audio cache directories to detect unexpected cross-user reads. 6. For deployments processing sensitive audio data, consider disabling audio caching entirely as a temporary workaround pending patch deployment.

What systems are affected by CVE-2026-10783?

This vulnerability affects the following AI/ML architecture patterns: ML demo deployments, model serving, audio processing pipelines, shared ML development environments.

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

CVE-2026-10783 has a CVSS v3.1 base score of 2.5 (LOW). The EPSS exploitation probability is 0.11%.

What is the AI security impact?

Affected AI Architectures

ML demo deploymentsmodel servingaudio processing pipelinesshared ML development environments

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0035 AI Artifact Collection

AML.T0037 Data from Local System

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.9.4

NIST AI RMF: PROTECT-2.2

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

A security flaw has been discovered in gradio-app gradio 6.14.0. This affects the function save_audio_to_cache of the component Audio Cache Key Handler. Performing a manipulation results in use of weak hash. The attack must be initiated from a local position. The attack is considered to have high complexity. It is indicated that the exploitability is difficult. The exploit has been released to the public and may be used for attacks. The patch is named 13394. To fix this issue, it is recommended to deploy a patch.

Exploitation Scenario

An attacker with a low-privilege local account on a shared ML development server analyzes the weak hash algorithm used by `save_audio_to_cache` in Gradio 6.14.0. By reverse-engineering the hash function from the public patch disclosure (#13394) and knowing predictable input parameters—such as filename and upload timestamp—the attacker computes expected cache key values for audio files submitted by other users. The attacker iterates over the likely hash space or exploits collisions to locate cached audio files on the shared filesystem, then reads them directly, exfiltrating voice recordings, proprietary audio training samples, or sensitive call recordings submitted by co-located users through the shared Gradio interface.

Weaknesses (CWE)

CWE-327 Use of a Broken or Risky Cryptographic Algorithm Primary CWE-327 Use of a Broken or Risky Cryptographic Algorithm Primary CWE-328 Use of Weak Hash Primary CWE-327 Use of a Broken or Risky Cryptographic Algorithm CWE-328 Use of Weak Hash

CWE-327 — Use of a Broken or Risky Cryptographic Algorithm: The product uses a broken or risky cryptographic algorithm or protocol.

[Architecture and Design] When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267
[Architecture and Design] Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.

Source: MITRE CWE corpus.