299 threats tracked across 7 launch stacks — sourced from NVD, GHSA, CISA KEV, OSV, npm Audit, and EPSS.
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.
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
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
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. ##
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Impact body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service. Patches this issue is patched in 1.20.3 References
An issue was discovered in llama_index before 0.10.38. download/integration.py includes an exec call for import {cls_name}.
axios 1.7.2 allows SSRF via unexpected behavior where requests for path relative URLs get processed as protocol relative URLs.
Summary Due to the insufficient validation of the path parameter in the NuxtTestComponentWrapper, an attacker can execute arbitrary JavaScript on the server side, which allows them to execute arbitrary commands. Details While running the test, a special component named NuxtTestComponentWrapper is available. https://github.com/nuxt/nuxt/blob/4779f5906fa4d3c784c2e2d6fe5a5c5f181faaec/packages/nuxt/src/app/components/nuxt-root.vue#L42-L43 This component loads the specified path as a component and renders it. https://github.com/nuxt/nuxt/blob/4779f5906fa4d3c784c2e2d6fe5a5c5f181faaec/packages/nuxt/src/app/components/test-component-wrapper.ts#L9-L27 There is a validation for the path parameter to check whether the path traversal is performed, but this check is not sufficient. https://github.com/nuxt/nuxt/blob/4779f5906fa4d3c784c2e2d6fe5a5c5f181faaec/packages/nuxt/src/app/components/test-component-wrapper.ts#L15-L19 Since import(...) uses query.path instead of the normalized path, a non-normalized URL can reach the import(...) function. For example, passing something like ./components/test normalizes path to /root/directory/components/test, but import(...) still receives ./components/test. By using this behavior, it's possible to load arbitrary JavaScript by using the path like the following: `` data:text/javascript;base64,Y29uc29sZS5sb2coMSk ` Since resolve(...) resolves the filesystem path, not the URI, the above URI is treated as a relative path, but import(...) sees it as an absolute URI, and loads it as a JavaScript. PoC 1. Create a nuxt project and run it in the test mode: ` npx nuxi@latest init test cd test TEST=true npm run dev ` 2. Open the following URL: ` http://localhost:3000/__nuxt_component_test__/?path=data%3Atext%2Fjavascript%3Bbase64%2CKGF3YWl0IGltcG9ydCgnZnMnKSkud3JpdGVGaWxlU3luYygnL3RtcC90ZXN0JywgKGF3YWl0IGltcG9ydCgnY2hpbGRfcHJvY2VzcycpKS5zcGF3blN5bmMoIndob2FtaSIpLnN0ZG91dCwgJ3V0Zi04Jyk ` 3. Confirm that the output of whoami is written to /tmp/test` Demonstration video: https://www.youtube.com/watch?v=FI6mN8WbcE4 Impact Users who open a malicious web page in the browser while running the test locally are affected by this vulnerability, which results in the remote code execution from the malicious web page. Since web pages can send requests to arbitrary addresses, a malicious web page can repeatedly try to exploit this vulnerability, which then triggers the exploit when the test server starts.
Impact A Denial of Service (DoS) condition was identified in Next.js. Exploitation of the bug can trigger a crash, affecting the availability of the server. This vulnerability can affect all Next.js deployments on the affected versions. Patches This vulnerability was resolved in Next.js 13.5 and later. We recommend that users upgrade to a safe version. Workarounds There are no official workarounds for this vulnerability. Credit Thai Vu of flyseccorp.com Aonan Guan (@0dd), Senior Cloud Security Engineer
Showing 81–100 of 182 threats