GHSA-j2jg-fq62-7c3h CVE-2025-23042 PYSEC-2025-118
Gradio Blocked Path ACL Bypass Vulnerability
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 1.00%
- Chance of exploitation in the next 30 days. Higher than 62.73% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
5.11.0- Upgrade gradio to this version or later
Description
Summary
Gradio's Access Control List (ACL) for file paths can be bypassed by altering the letter case of a blocked file or directory path. This vulnerability arises due to the lack of case normalization in the file path validation logic. On case-insensitive file systems, such as those used by Windows and macOS, this flaw enables attackers to circumvent security restrictions and access sensitive files that should be protected.
This issue can lead to unauthorized data access, exposing sensitive information and undermining the integrity of Gradio's security model. Given Gradio's popularity for building web applications, particularly in machine learning and AI, this vulnerability may pose a substantial threat if exploited in production environments.
Affected Version
Gradio <= 5.6.0
Impact
-
Unauthorized Access: Sensitive files or directories specified in
blocked_pathscan be accessed by attackers. -
Data Exposure: Critical files, such as configuration files or user data, may be leaked.
-
Security Breach: This can lead to broader application or system compromise if sensitive files contain credentials or API keys.
Root Cause
The blocked_paths parameter in Gradio block's initial configuration is designed to restrict user access to specific files or directories in the local file system. However, it does not account for case-insensitive operating systems, such as Windows and macOS. This oversight enables attackers to bypass ACL restrictions by changing the case of file paths.
Vulnerable snippet:
# https://github.com/gradio-app/gradio/blob/main/gradio/utils.py#L1500-L1517
def is_allowed_file(
path: Path,
blocked_paths: Sequence[str | Path],
allowed_paths: Sequence[str | Path],
created_paths: Sequence[str | Path],
) -> tuple[
bool, Literal["in_blocklist", "allowed", "created", "not_created_or_allowed"]
]:
in_blocklist = any(
is_in_or_equal(path, blocked_path) for blocked_path in blocked_paths
)
if in_blocklist:
return False, "in_blocklist"
if any(is_in_or_equal(path, allowed_path) for allowed_path in allowed_paths):
return True, "allowed"
if any(is_in_or_equal(path, created_path) for created_path in created_paths):
return True, "created"
return False, "not_created_or_allowed"
Gradio relies on is_in_or_equal to determine if a file path is restricted. However, this logic fails to handle case variations in paths on case-insensitive file systems, leading to the bypass.
Proof of Concept (PoC)
Steps to Reproduce
-
Deploy a Gradio demo app on a case-insensitive operating system (e.g., Windows or macOS).
import gradio as gr def update(name): return f"Welcome to Gradio, {name}!" with gr.Blocks() as demo: gr.Markdown("Start typing below and then click **Run** to see the output.") with gr.Row(): inp = gr.Textbox(placeholder="What is your name?") out = gr.Textbox() btn = gr.Button("Run") btn.click(fn=update, inputs=inp, outputs=out) demo.launch(blocked_paths=['resources/admin'], allowed_paths=['resources/']) -
Set up the file system:
-
Create a folder named
resourcesin the same directory as the app, containing a file1.txt. -
Inside the
resourcesfolder, create a subfolder namedadmincontaining a sensitive filecredential.txt(this file should be inaccessible due toblocked_paths).
-
-
Perform the attack:
-
Access the sensitive file using a case-altered path:
http://127.0.0.1:PORT/gradio_api/file=resources/adMin/credential.txt
-
Expected Result
Access to resources/admin/credential.txt should be blocked.
Actual Result
By altering the case in the path (e.g., adMin), the blocked ACL is bypassed, and unauthorized access to the sensitive file is granted.
This demonstration highlights that flipping the case of restricted paths allows attackers to bypass Gradio's ACL and access sensitive data.
Remediation Recommendations
-
Normalize Path Case:
-
Before evaluating paths against the ACL, normalize the case of both the requested path and the blocked paths (e.g., convert all paths to lowercase).
-
Example:
normalized_path = str(path).lower() normalized_blocked_paths = [str(p).lower() for p in blocked_paths]
-
-
Update Documentation:
- Warn developers about potential risks when deploying Gradio on case-insensitive file systems.
-
Release Security Patches:
- Notify users of the vulnerability and release an updated version of Gradio with the fixed logic.
Affected versions
PyPI
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
gradio PyPI → 5.11.0
- pip
pip install --upgrade "gradio>=5.11.0"- poetry
poetry add "gradio>=5.11.0"- uv
uv add "gradio>=5.11.0"
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-178: Improper Handling of Case Sensitivity
The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
How to prevent it
- Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
- 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, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CWE-285: Improper Authorization
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
How to prevent it
- Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- Architecture and Design: Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.
- 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. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
- Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
- System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-j36p-7w88-g82j Gradio FileExplorer preprocess path traversal allows files outside root_dir to reach callbacks | High | Also affects gradio |
| GHSA-6655-8ph2-63j3 Gradio: Audio cache key ignores metadata when saving numpy audio outputs | Low | Also affects gradio |
| GHSA-7hp7-4p35-3cx2 Gradio contains a cookie injection vulnerability | Medium | Also affects gradio |
| GHSA-jmh7-g254-2cq9 Gradio has SSRF via Malicious `proxy_url` Injection in `gr.load()` Config Processing | High | Also affects gradio |
| GHSA-pfjf-5gxr-995x Gradio has an Open Redirect in its OAuth Flow | Medium | Also affects gradio |
| GHSA-39mp-8hj3-5c49 Gradio is Vulnerable to Absolute Path Traversal on Windows with Python 3.13+ | High | Also affects gradio |
| GHSA-h3h8-3v2v-rg7m Gradio: Mocked OAuth Login Exposes Server Credentials and Uses Hardcoded Session Secret | Medium | Also affects gradio |
| GHSA-8jw3-6x8j-v96g Gradio Allows Unauthorized File Copy via Path Manipulation | High | Also affects gradio |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor