Gradio has an XSS on every Gradio server via upload of HTML files, JS files, or SVG files
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability involves Cross-Site Scripting (XSS) on any Gradio server that allows file uploads. Authenticated users can upload files such as HTML, JavaScript, or SVG files containing malicious scripts. When other users download or view these files, the scripts will execute in their browser, allowing attackers to perform unauthorized actions or steal sensitive information from their sessions. This impacts any Gradio server that allows file uploads, particularly those using components that process or display user-uploaded files.
Patches
Yes, please upgrade to gradio>=5 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can restrict the types of files that can be uploaded to the Gradio server by limiting uploads to non-executable file types such as images or text. Additionally, developers can implement server-side validation to sanitize uploaded files, ensuring that HTML, JavaScript, and SVG files are properly handled or rejected before being stored or displayed to users.
Gradio has several components with post-process steps allow arbitrary file leaks
Impact
What kind of vulnerability is it? Who is impacted?
This is a data validation vulnerability affecting several Gradio components, which allows arbitrary file leaks through the post-processing step. Attackers can exploit these components by crafting requests that bypass expected input constraints. This issue could lead to sensitive files being exposed to unauthorized users, especially when combined with other vulnerabilities, such as issue TOB-GRADIO-15. The components most at risk are those that return or handle file data.
Vulnerable Components:
1. String to FileData: DownloadButton, Audio, ImageEditor, Video, Model3D, File, UploadButton.
2. Complex data to FileData: Chatbot, MultimodalTextbox.
3. Direct file read in preprocess: Code.
4. Dictionary converted to FileData: ParamViewer, Dataset.
Exploit Scenarios:
1. A developer creates a Dropdown list that passes values to a DownloadButton. An attacker bypasses the allowed inputs, sends an arbitrary file path (like /etc/passwd), and downloads sensitive files.
2. An attacker crafts a malicious payload in a ParamViewer component, leaking sensitive files from a server through the arbitrary file leak.
Patches
Yes, the issue has been resolved in gradio>5.0. Upgrading to the latest version will mitigate this vulnerability.
Gradio vulnerable to SSRF in the path parameter of /queue/join
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability relates to Server-Side Request Forgery (SSRF) in the /queue/join endpoint. Gradio’s async_save_url_to_cache function allows attackers to force the Gradio server to send HTTP requests to user-controlled URLs. This could enable attackers to target internal servers or services within a local network and possibly exfiltrate data or cause unwanted internal requests. Additionally, the content from these URLs is stored locally, making it easier for attackers to upload potentially malicious files to the server. This impacts users deploying Gradio servers that use components like the Video component which involve URL fetching.
Patches
Yes, please upgrade to gradio>=5 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can disable or heavily restrict URL-based inputs in their Gradio applications to trusted domains only. Additionally, implementing stricter URL validation (such as allowinglist-based validation) and ensuring that local or internal network addresses cannot be requested via the /queue/join endpoint can help mitigate the risk of SSRF attacks.
Gradio has a one-level read path traversal in `/custom_component`
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability involves a one-level read path traversal in the /custom_component endpoint. Attackers can exploit this flaw to access and leak source code from custom Gradio components by manipulating the file path in the request. Although the traversal is limited to a single directory level, it could expose proprietary or sensitive code that developers intended to keep private. This impacts users who have developed custom Gradio components and are hosting them on publicly accessible servers.
Patches
Yes, please upgrade to gradio>=4.44 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, developers can sanitize the file paths and ensure that components are not stored in publicly accessible directories.
Gradio's CORS origin validation accepts the null origin
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability relates to CORS origin validation accepting a null origin. When a Gradio server is deployed locally, the localhost_aliases variable includes "null" as a valid origin. This allows attackers to make unauthorized requests from sandboxed iframes or other sources with a null origin, potentially leading to data theft, such as user authentication tokens or uploaded files. This impacts users running Gradio locally, especially those using basic authentication.
Patches
Yes, please upgrade to gradio>=5.0 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can manually modify the localhost_aliases list in their local Gradio deployment to exclude "null" as a valid origin. By removing this value, the Gradio server will no longer accept requests from sandboxed iframes or sources with a null origin, mitigating the potential for exploitation.
OWASP A01OWASP A05LLM06 · Sensitive Info DisclosureOWASP LLM
Get guardrail →Gradio's `is_in_or_equal` function may be bypassed
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability relates to the bypass of directory traversal checks within the is_in_or_equal function. This function, intended to check if a file resides within a given directory, can be bypassed with certain payloads that manipulate file paths using .. (parent directory) sequences. Attackers could potentially access restricted files if they are able to exploit this flaw, although the difficulty is high. This primarily impacts users relying on Gradio’s blocklist or directory access validation, particularly when handling file uploads.
Patches
Yes, please upgrade to gradio>=5.0 to address this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
As a workaround, users can manually sanitize and normalize file paths in their Gradio deployment before passing them to the is_in_or_equal function. Ensuring that all file paths are properly resolved and absolute can help mitigate the bypass vulnerabilities caused by the improper handling of .. sequences or malformed paths.
vLLM Denial of Service via the best_of parameter
A vulnerability was found in the ilab model serve component, where improper handling of the best_of parameter in the vllm JSON web API can lead to a Denial of Service (DoS). The API used for LLM-based sentence or chat completion accepts a best_of parameter to return the best completion from several options. When this parameter is set to a large value, the API does not handle timeouts or resource exhaustion properly, allowing an attacker to cause a DoS by consuming excessive system resources. This leads to the API becoming unresponsive, preventing legitimate users from accessing the service.
Open redirect in gradio
An open redirect vulnerability exists in the gradio-app/gradio, affecting the latest version. The vulnerability allows an attacker to redirect users to arbitrary websites, which can be exploited for phishing attacks, Cross-site Scripting (XSS), Server-Side Request Forgery (SSRF), amongst others. This issue is due to improper validation of user-supplied input in the handling of URLs. Attackers can exploit this vulnerability by crafting a malicious URL that, when processed by the application, redirects the user to an attacker-controlled web page.
Server-Side Request Forgery in langchain-community.retrievers.web_research.WebResearchRetriever
A Server-Side Request Forgery (SSRF) vulnerability exists in the Web Research Retriever component in langchain-community (langchain-community.retrievers.web_research.WebResearchRetriever). The vulnerability arises because the Web Research Retriever does not restrict requests to remote internet addresses, allowing it to reach local addresses. This flaw enables attackers to execute port scans, access local services, and in some scenarios, read instance metadata from cloud environments. The vulnerability is particularly concerning as it can be exploited to abuse the Web Explorer server as a proxy for web attacks on third parties and interact with servers in the local network, including reading their response data. This could potentially lead to arbitrary code execution, depending on the nature of the local services. The vulnerability is limited to GET requests, as POST requests are not possible, but the impact on confidentiality, integrity, and availability is significant due to the potential for stolen credentials and state-changing interactions with internal APIs.
The patched code:
Requires users to opt-in
Suggests using a proxy to prevent requests to local addresses
Denial of service in langchain-community
Denial of service in SitemapLoader Document Loader in the langchain-community package, affecting versions below 0.2.5. The parse_sitemap method, responsible for parsing sitemaps and extracting URLs, lacks a mechanism to prevent infinite recursion when a sitemap URL refers to the current sitemap itself. This oversight allows for the possibility of an infinite loop, leading to a crash by exceeding the maximum recursion depth in Python. This vulnerability can be exploited to occupy server socket/port resources and crash the Python process, impacting the availability of services relying on this functionality.
Gradio applications running locally vulnerable to 3rd party websites accessing routes and uploading files
Impact
This CVE covers the ability of 3rd party websites to access routes and upload files to users running Gradio applications locally. For example, the malicious owners of www.dontvisitme.com could put a script on their website that uploads a large file to http://localhost:7860/upload and anyone who visits their website and has a Gradio app will now have that large file uploaded on their computer
Patches
Yes, the problem has been patched in Gradio version 4.19.2 or higher. We have no knowledge of this exploit being used against users of Gradio applications, but we encourage all users to upgrade to Gradio 4.19.2 or higher.
Fixed in: https://github.com/gradio-app/gradio/commit/84802ee6a4806c25287344dce581f9548a99834a
CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-1727
Gradio's Component Server does not properly consider` _is_server_fn` for functions
Component Server in Gradio before 4.13 does not properly consider _is_server_fn for functions.
langchain vulnerable to path traversal
langchain-ai/langchain is vulnerable to path traversal due to improper limitation of a pathname to a restricted directory ('Path Traversal') in its LocalFileStore functionality. An attacker can leverage this vulnerability to read or write files anywhere on the filesystem, potentially leading to information disclosure or remote code execution. The issue lies in the handling of file paths in the mset and mget methods, where user-supplied input is not adequately sanitized, allowing directory traversal sequences to reach unintended directories.
gradio Server-Side Request Forgery vulnerability
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.
LangChain's XMLOutputParser vulnerable to XML Entity Expansion
The XMLOutputParser in LangChain uses the etree module from the XML parser in the standard python library which has some XML vulnerabilities; see: https://docs.python.org/3/library/xml.html
This primarily affects users that combine an LLM (or agent) with the XMLOutputParser and expose the component via an endpoint on a web-service.
This would allow a malicious party to attempt to manipulate the LLM to produce a malicious payload for the parser that would compromise the availability of the service.
A successful attack is predicated on:
1. Usage of XMLOutputParser
2. Passing of malicious input into the XMLOutputParser either directly or by trying to manipulate an LLM to do so on the users behalf
3. Exposing the component via a web-service
Gradio apps vulnerable to timing attacks to guess password
Impact
This security policy is with regards to a timing attack that allows users of Gradio apps to potentially guess the password of password-protected Gradio apps. This relies on the fact that string comparisons in Python terminate early, as soon as there is a string mismatch. Because Gradio apps are, by default, not rate-limited, a user could brute-force millions of guesses to figure out the correct username and password.
Patches
Yes, the problem has been patched in Gradio version 4.19.2 or higher. We have no knowledge of this exploit being used against users of Gradio applications, but we encourage all users to upgrade to Gradio 4.19.2 or higher.
Fixed in: https://github.com/gradio-app/gradio/commit/e329f1fd38935213fe0e73962e8cbd5d3af6e87b
Gradio arbitrary file upload vulnerability
Gradio v3.27.0 was discovered to contain an arbitrary file upload vulnerability via the /upload interface.
Gradio vulnerable to arbitrary file read and proxying of arbitrary URLs
Impact
There are two separate security vulnerabilities here: (1) a security vulnerability that allows users to read arbitrary files on the machines that are running shared Gradio apps (2) the ability of users to use machines that are sharing Gradio apps to proxy arbitrary URLs
Patches
Both problems have been solved, please upgrade gradio to 3.34.0 or higher
Workarounds
Not possible to workaround except by taking down any shared Gradio apps
References
Relevant PRs:
https://github.com/gradio-app/gradio/pull/4406
https://github.com/gradio-app/gradio/pull/4370
transformers has Insecure Temporary File
Insecure Temporary File in GitHub repository huggingface/transformers 4.29.2 and prior. A fix is available at commit 80ca92470938bbcc348e2d9cf4734c7c25cb1c43 and has been released as part of version 4.30.0.
Update share links to use FRP instead of SSH tunneling
Impact
This is a vulnerability which affects anyone using Gradio's share links (i.e. creating a Gradio app and then setting share=True) with Gradio versions older than 3.13.1. In these older versions of Gradio, a private SSH key is sent to any user that connects to the Gradio machine, which means that a user could access other users' shared Gradio demos. From there, other exploits are possible depending on the level of access/exposure the Gradio app provides.
Patches
The problem has been patched. Ideally, users should upgrade to gradio==3.19.1 or later where the FRP solution has been properly tested.
Credit
Credit to Greg Sadetsky and Samuel Tremblay-Cossette for alerting the team
