Transformers Regular Expression Denial of Service (ReDoS) vulnerability
A Regular Expression Denial of Service (ReDoS) vulnerability was identified in the huggingface/transformers library, specifically in the file tokenization_nougat_fast.py. The vulnerability occurs in the post_process_single() function, where a regular expression processes specially crafted input. The issue stems from the regex exhibiting exponential time complexity under certain conditions, leading to excessive backtracking. This can result in significantly high CPU usage and potential application downtime, effectively creating a Denial of Service (DoS) scenario. The affected version is v4.46.3.
LlamaIndex Improper Handling of Exceptional Conditions vulnerability
A vulnerability in the LangChainLLM class of the run-llama/llama_index repository, version v0.12.5, allows for a Denial of Service (DoS) attack. The stream_complete method executes the llm using a thread and retrieves the result via the get_response_gen method of the StreamingGeneratorCallbackHandler class. If the thread terminates abnormally before the _llm.predict is executed, there is no exception handling for this case, leading to an infinite loop in the get_response_gen function. This can be triggered by providing an input of an incorrect type, causing the thread to terminate and the process to continue running indefinitely.
vLLM Deserialization of Untrusted Data vulnerability
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. The function uses pickle.loads to parse received sockets directly, leading to a remote code execution vulnerability. An attacker can exploit this by sending a malicious payload to the MessageQueue, causing the victim's machine to execute arbitrary code.
Gradio Vulnerable to Arbitrary File Deletion
A path traversal vulnerability exists in the Gradio Audio component of gradio-app/gradio, as of version git 98cbcae. This vulnerability allows an attacker to control the format of the audio file, leading to arbitrary file content deletion. By manipulating the output format, an attacker can reset any file to an empty file, causing a denial of service (DOS) on the server.
Gradio Vulnerable to Denial of Service (DoS) via Crafted HTTP Request
A Regular Expression Denial of Service (ReDoS) vulnerability exists in the gradio-app/gradio repository, affecting the gr.Datetime component. The affected version is git commit 98cbcae. The vulnerability arises from the use of a regular expression ^(?:\snow\s(?:-\s(\d+)\s([dmhs]))?)?\s*$ to process user input. In Python's default regex engine, this regular expression can take polynomial time to match certain crafted inputs. An attacker can exploit this by sending a crafted HTTP request, causing the gradio process to consume 100% CPU and potentially leading to a Denial of Service (DoS) condition on the server.
Gradio Vulnerable to Denial of Service (DoS) via Crafted Zip Bomb
A vulnerability in the dataframe component of gradio-app/gradio (version git 98cbcae) allows for a zip bomb attack. The component uses pd.read_csv to process input values, which can accept compressed files. An attacker can exploit this by uploading a maliciously crafted zip bomb, leading to a server crash and causing a denial of service.
vLLM Allows Remote Code Execution via Mooncake Integration
Summary
When vLLM is configured to use Mooncake, unsafe deserialization exposed directly over ZMQ/TCP will allow attackers to execute remote code on distributed hosts.
Details
1. Pickle deserialization vulnerabilities are well documented.
2. The mooncake pipe is exposed over the network (by design to enable disaggregated prefilling across distributed environments) using ZMQ over TCP, greatly increasing exploitability. ~~Further, the mooncake integration opens these sockets listening on all interfaces on the host, meaning it can not be configured to only use a private, trusted network.~~
Only sender_socket and receiver_ack are allowed to be accessed publicly, while the data actually decompressed by pickle.loads() comes from recv_bytes. Its interface is defined as self.receiver_socket.connect(f\"tcp://{d_host}:{d_rank_offset + 1}\"), where d_host is decode_host, a locally defined address 192.168.0.139,from mooncake.json (https://github.com/kvcache-ai/Mooncake/blob/main/doc/en/vllm-integration-v0.2.md?plain=1#L36).
3. The root problem is recv_tensor() calls _recv_impl which passes the raw network bytes to pickle.loads(). Additionally, it does not appear that there are any controls (network, authentication, etc) to prevent arbitrary users from sending this payload to the affected service.
Impact
This is a remote code execution vulnerability impacting any deployments using Mooncake to distribute KV across distributed hosts.
Remediation
This issue is resolved by https://github.com/vllm-project/vllm/pull/14228
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 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 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.
Gradios's CORS origin validation is not performed when the request has a cookie
Impact
What kind of vulnerability is it? Who is impacted?
This vulnerability is related to CORS origin validation, where the Gradio server fails to validate the request origin when a cookie is present. This allows an attacker’s website to make unauthorized requests to a local Gradio server. Potentially, attackers can upload files, steal authentication tokens, and access user data if the victim visits a malicious website while logged into Gradio. This impacts users who have deployed Gradio locally and use basic authentication.
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, users can manually enforce stricter CORS origin validation by modifying the CustomCORSMiddleware class in their local Gradio server code. Specifically, they can bypass the condition that skips CORS validation for requests containing cookies to prevent potential exploitation.
OWASP A01OWASP A05LLM06 · Sensitive Info DisclosureOWASP LLM
Get guardrail →Gradio allows users to access arbitrary files
Impact
This vulnerability allows users of Gradio applications that have a public link (such as on Hugging Face Spaces) to access files on the machine hosting the Gradio application. This involves intercepting and modifying the network requests made by the Gradio app to the server.
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/16fbe9cd0cffa9f2a824a0165beb43446114eec7
CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-1728
vLLM denial of service vulnerability
A flaw was found in the vLLM library. A completions API request with an empty prompt will crash the vLLM API server, resulting in a denial of service.
LangChain pickle deserialization of untrusted data
A vulnerability in the FAISS.deserialize_from_bytes function of langchain-ai/langchain allows for pickle deserialization of untrusted data. This can lead to the execution of arbitrary commands via the os.system function. The issue affects versions prior to 0.2.4.
LlamaIndex includes an exec call for `import {cls_name}`
An issue was discovered in llama_index before 0.10.38. download/integration.py includes an exec call for import {cls_name}.
