vLLM denial of service via outlines unbounded cache on disk
Impact
The outlines library is one of the backends used by vLLM to support structured output (a.k.a. guided decoding). Outlines provides an optional cache for its compiled grammars on the local filesystem. This cache has been on by default in vLLM. Outlines is also available by default through the OpenAI compatible API server.
The affected code in vLLM is vllm/model_executor/guided_decoding/outlines_logits_processors.py, which unconditionally uses the cache from outlines. vLLM should have this off by default and allow administrators to opt-in due to the potential for abuse.
A malicious user can send a stream of very short decoding requests with unique schemas, resulting in an addition to the cache for each request. This can result in a Denial of Service if the filesystem runs out of space.
Note that even if vLLM was configured to use a different backend by default, it is still possible to choose outlines on a per-request basis using the guided_decoding_backend key of the extra_body field of the request.
This issue applies to the V0 engine only. The V1 engine is not affected.
Patches
https://github.com/vllm-project/vllm/pull/14837
The fix is to disable this cache by default since it does not provide an option to limit its size. If you want to use this cache anyway, you may set the VLLM_V0_USE_OUTLINES_CACHE environment variable to 1.
Workarounds
There is no way to workaround this issue in existing versions of vLLM other than preventing untrusted access to the OpenAI compatible API server.
References
vllm: Malicious model to RCE by torch.load in hf_model_weights_iterator
Description
The vllm/model_executor/weight_utils.py implements hf_model_weights_iterator to load the model checkpoint, which is downloaded from huggingface. It use torch.load function and weights_only parameter is default value False. There is a security warning on https://pytorch.org/docs/stable/generated/torch.load.html, when torch.load load a malicious pickle data it will execute arbitrary code during unpickling.
Impact
This vulnerability can be exploited to execute arbitrary codes and OS commands in the victim machine who fetch the pretrained repo remotely.
Note that most models now use the safetensors format, which is not vulnerable to this issue.
References
https://pytorch.org/docs/stable/generated/torch.load.html
Fix: https://github.com/vllm-project/vllm/pull/12366
Gradio Blocked Path ACL Bypass Vulnerability
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_paths can 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:
``python
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).
`bash
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 resources in the same directory as the app, containing a file 1.txt.
Inside the resources folder, create a subfolder named admin containing a sensitive file credential.txt (this file should be inaccessible due to blocked_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.
!image-20241119172439042
This demonstration highlights that flipping the case of restricted paths allows attackers to bypass Gradio's ACL and access sensitive data.
Remediation Recommendations
1. 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:
`python
normalized_path = str(path).lower()
normalized_blocked_paths = [str(p).lower() for p in blocked_paths]
``
2. Update Documentation:
Warn developers about potential risks when deploying Gradio on case-insensitive file systems.
3. Release Security Patches:
Notify users of the vulnerability and release an updated version of Gradio with the fixed logic.
##
Deserialization of Untrusted Data in Hugging Face Transformers
Hugging Face Transformers Trax Model Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.
The specific flaw exists within the handling of model files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25012.
Deserialization of Untrusted Data in Hugging Face Transformers
Hugging Face Transformers MaskFormer Model Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.
The specific flaw exists within the parsing of model files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-25191.
Deserialization of Untrusted Data in Hugging Face Transformers
Hugging Face Transformers MobileViTV2 Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Hugging Face Transformers. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.
The specific flaw exists within the handling of configuration files. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-24322.
Gradio vulnerable to arbitrary file read with File and UploadButton components
Summary
If File or UploadButton components are used as a part of Gradio application to preview file content, an attacker with access to the application might abuse these components to read arbitrary files from the application server.
Details
Consider the following application where a user can upload a file and preview its content:
``
import gradio as gr
def greet(value: bytes):
return str(value)
demo = gr.Interface(fn=greet, inputs=gr.File(type="binary"), outputs="textbox")
if __name__ == "__main__":
demo.launch()
`
If we run this application and make the following request (which attempts to read the /etc/passwd file)
`
curl 'http://127.0.0.1:7860/gradio_api/run/predict' -H 'content-type: application/json' --data-raw '{"data":[{"path":"/etc/passwd","orig_name":"test.txt","size":4,"mime_type":"text/plain","meta":{"_type":"gradio.FileData"}}],"event_data":null,"fn_index":0,"trigger_id":8,"session_hash":"mnv42s5gt7"}'
`
Then this results in the following error on the server
`
gradio.exceptions.InvalidPathError: Cannot move /etc/passwd to the gradio cache dir because it was not uploaded by a user.
`
This is expected. However, if we now remove the "meta":{"_type":"gradio.FileData"} from the request:
`
curl 'http://127.0.0.1:7860/gradio_api/run/predict' -H 'content-type: application/json' --data-raw '{"data":[{"path":"/etc/passwd","orig_name":"test.txt","size":4,"mime_type":"text/plain"}],"event_data":null,"fn_index":0,"trigger_id":8,"session_hash":"mnv42s5gt7"}'
`
This doesn't cause an error and results in the content of /etc/passwd being shown in the response!
This works because Gradio relies on the processing_utils.async_move_files_to_cache to sanitize all incoming file paths in all inputs. This function performs the following operation
`
return await client_utils.async_traverse(
data, _move_to_cache, client_utils.is_file_obj_with_meta
)
`
where client_utils.is_file_obj_with_meta is used as a filter which tells on which inputs to perform the _move_to_cache function (which also performs the allowed/disallowed check on the file path). The problem is that client_utils.is_file_obj_with_meta is not guaranteed to trigger for every input that contains a file path:
`
def is_file_obj_with_meta(d) -> bool:
"""
Check if the given value is a valid FileData object dictionary in newer versions of Gradio
where the file objects include a specific "meta" key, e.g.
{
"path": "path/to/file",
"meta": {"_type: "gradio.FileData"}
}
"""
return (
isinstance(d, dict)
and "path" in d
and isinstance(d["path"], str)
and "meta" in d
and d["meta"].get("_type", "") == "gradio.FileData"
)
`
For example, as in the PoC, the file path won't be checked if the meta key is not present in the request or if _type is not gradio.FileData.
Then, the path remains under control of the attacker and is used to read a file in _process_single_file function in file.py and upload_button.py (and possibly other places)
PoC
As described above, run the following Gradio app
`
import gradio as gr
def greet(value: bytes):
return str(value)
demo = gr.Interface(fn=greet, inputs=gr.File(type="binary"), outputs="textbox")
if __name__ == "__main__":
demo.launch()
`
And make the following request
`
curl 'http://127.0.0.1:7860/gradio_api/run/predict' -H 'content-type: application/json' --data-raw '{"data":[{"path":"/etc/passwd","orig_name":"test.txt","size":4,"mime_type":"text/plain"}],"event_data":null,"fn_index":0,"trigger_id":8,"session_hash":"mnv42s5gt7"}'
``
Impact
Arbitrary file read in specific Gradio applications that use File or UploadButton components to upload files and echo/preview the content to the user.
gradio Server Side Request Forgery vulnerability
In gradio <=4.42.0, the gr.DownloadButton function has a hidden server-side request forgery (SSRF) vulnerability. The reason is that within the save_url_to_cache function, there are no restrictions on the URL, which allows access to local target resources. This can lead to the download of local resources and sensitive information.
Express ressource injection
A vulnerability has been identified in the Express response.links function, allowing for arbitrary resource injection in the Link header when unsanitized data is used.
The issue arises from improper sanitization in Link header values, which can allow a combination of characters like ,, ;, and <> to preload malicious resources.
This vulnerability is especially relevant for dynamic parameters.
Starlette Denial of service (DoS) via multipart/form-data
Summary
Starlette treats multipart/form-data parts without a filename as text form fields and buffers those in byte strings with no size limit. This allows an attacker to upload arbitrary large form fields and cause Starlette to both slow down significantly due to excessive memory allocations and copy operations, and also consume more and more memory until the server starts swapping and grinds to a halt, or the OS terminates the server process with an OOM error. Uploading multiple such requests in parallel may be enough to render a service practically unusable, even if reasonable request size limits are enforced by a reverse proxy in front of Starlette.
PoC
``python
from starlette.applications import Starlette
from starlette.routing import Route
async def poc(request):
async with request.form():
pass
app = Starlette(routes=[
Route('/', poc, methods=["POST"]),
])
`
`sh
curl http://localhost:8000 -F 'big=</dev/urandom'
``
Impact
This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) accepting form requests.
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 uses insecure communication between the FRP client and server
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability involves insecure communication between the FRP (Fast Reverse Proxy) client and server when Gradio's share=True option is used. HTTPS is not enforced on the connection, allowing attackers to intercept and read files uploaded to the Gradio server, as well as modify responses or data sent between the client and server. This impacts users who are sharing Gradio demos publicly over the internet using share=True without proper encryption, exposing sensitive data to potential eavesdroppers.
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 avoid using share=True in production environments and instead host their Gradio applications on servers with HTTPS enabled to ensure secure communication.
Gradio has a race condition in update_root_in_config may redirect user traffic
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability involves a race condition in the update_root_in_config function, allowing an attacker to modify the root URL used by the Gradio frontend to communicate with the backend. By exploiting this flaw, an attacker can redirect user traffic to a malicious server. This could lead to the interception of sensitive data such as authentication credentials or uploaded files. This impacts all users who connect to a Gradio server, especially those exposed to the internet, where malicious actors could exploit this race condition.
Patches
Yes, please upgrade to gradio>=5 to address this issue.
Gradio performs a non-constant-time comparison when comparing hashes
Impact
What kind of vulnerability is it? Who is impacted?
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.
Patches
Yes, please upgrade to gradio>4.44 to mitigate this issue.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
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.
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 lacks integrity checking on the downloaded FRP client
Impact
This vulnerability is a lack of integrity check on the downloaded FRP client, which could potentially allow attackers to introduce malicious code. If an attacker gains access to the remote URL from which the FRP client is downloaded, they could modify the binary without detection, as the Gradio server does not verify the file's checksum or signature.
Who is impacted?
Any users utilizing the Gradio server's sharing mechanism that downloads the FRP client could be affected by this vulnerability, especially those relying on the executable binary for secure data tunneling.
Patches
Yes, please upgrade to gradio>=5.0, which includes a fix to verify the integrity of the downloaded binary.
Workarounds
There is no direct workaround for this issue without upgrading. However, users can manually validate the integrity of the downloaded FRP client by implementing checksum or signature verification in their own environment to ensure the binary hasn't been tampered with.
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.
