Russellb

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.10.2 through 0.12.x **Description** Multimodal embeddings processing lacks sparse tensor validation. Since PyTorch disables sparse tensor invariant checks by default, an attacker can submit crafted embedding requests containing malformed tensor indices, such as negative or out-of-bounds values, when the `prompt-embeds` feature is enabled. This can lead to crashes, resource exhaustion resulting in denial of service, or potential out-of-bounds/write-what-where memory corruption. **Recommendations** Update to version 0.13.0 or later. As a temporary workaround, disable the `prompt-embeds` feature to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.11.0rc2 **Description** vLLM is an inference and serving engine for large language models (LLMs). The API key validation mechanism in versions prior to 0.11.0rc2 is susceptible to a timing attack. The string comparison used for validation takes longer as more characters of the provided API key match the expected key. By analyzing the time taken for multiple validation attempts, an attacker could potentially determine the correct characters in the key sequence, leading to authentication bypass. The API key validation process is vulnerable. **Recommendations** Update to version 0.11.0rc2 or later.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.8.0 through 0.9.0 **Description** The vLLM backend used with the "/v1/chat/completions" API endpoint fails to validate unexpected or malformed input in the `pattern` and `type` fields when the tools functionality is invoked. These inputs are not validated before being compiled or parsed, causing a crash of the inference worker with a single request. The worker will remain down until it is restarted. The `type` field is expected to be one of: "string", "number", "object", "boolean", "array", or "null". Supplying any other value will cause the worker to crash. The `pattern` field undergoes rendering prior to being passed unsafely into the native regex compiler without validation or escaping, allowing malformed expressions to reach the underlying C++ regex engine, resulting in fatal errors. **Recommendations** For versions 0.8.0 through 0.9.0, update to version 0.9.0 to fix the issue. As a temporary workaround, consider restricting access to the `/v1/chat/completions` API endpoint or disabling the tools functionality until a patch is available. Avoid using the `pattern` and `type` fields in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.6.3 through 0.8.x **Description** Multiple regular expression denial of service (ReDoS) issues exist where several regex patterns are susceptible to catastrophic backtracking—a condition where a complex regex takes an exponential amount of time to process certain inputs. This can be triggered by an attacker submitting crafted input with nested or repeated structures, leading to severe CPU consumption and performance degradation. The affected components include the OpenAI-compatible serving chat endpoint, the phi4mini tool parser, and the `vllm/lora/utils.py` file. **Recommendations** Update to version 0.9.0 or later.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.5.2 through 0.8.5 **Description** The issue affects vLLM, a high-throughput and memory-efficient inference and serving engine for LLMs. In a multi-node vLLM deployment, vLLM uses ZeroMQ for some multi-node communication purposes, opening an XPUB ZeroMQ socket and binding it to all interfaces. This allows any client with network access to connect to the socket, unless its port is blocked by a firewall, and receive internal vLLM state information. Although this data is not useful to an attacker, connecting to the socket multiple times without reading the published data can cause a denial of service by slowing down or potentially blocking the publisher. **Recommendations** For versions 0.5.2 through 0.8.5, update to version 0.8.5 to resolve the issue. As a temporary workaround, consider blocking the port used by the XPUB ZeroMQ socket to prevent unauthorized access. Restrict access to the ZeroMQ socket to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.9.0 **Description** The issue arises from the prefix caching mechanism in vLLM, which may expose the system to a timing side-channel attack. When a new prompt is processed, if the PageAttention mechanism finds a matching prefix chunk, the prefill process speeds up, reflected in the Time to First Token (TTFT). The timing differences caused by matching chunks are significant enough to be recognized and exploited, potentially leading to the leakage of private information. An attacker could attempt to guess a victim's input by measuring the TTFT based on prefix matches, allowing them to verify if their guess is correct. **Recommendations** For versions prior to 0.9.0, update to version 0.9.0 to resolve the issue. As a temporary workaround, consider adjusting the chunk size parameter to minimize the risk of exploitation. Restrict access to sensitive prompts and valuable system prompts to minimize the risk of private information leakage. Avoid using the PageAttention mechanism with short prefix lengths, as it may increase the vulnerability to timing side-channel attacks.

Name of the Vulnerable Software and Affected Versions: XGrammar versions prior to 0.1.18 Description: The issue concerns an unbounded cache for compiled grammars in memory, which can be exploited to cause a denial of service by filling up a host's memory. This can occur when a system using XGrammar receives many small requests with unique JSON schemas, such as sending multiple requests to an LLM inference server. Recommendations: For versions prior to 0.1.18, update to version 0.1.18 to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** vLLM versions 0.6.5 through 0.8.4 **Description** vLLM, an inference and serving engine for large language models (LLMs), contains a remote code execution issue. This impacts environments utilizing the `PyNcclPipe` KV cache transfer integration with the V0 engine. The issue stems from the use of `pickle.loads` to process client-provided data within the `PyNcclPipe` implementation, creating an unsafe deserialization vulnerability. An attacker can exploit this by sending malicious serialized data to gain server control privileges. The `PyNcclPipe` class is used to establish peer-to-peer communication for data transmission between distributed nodes, and the GPU-side KV-Cache transmission is implemented through the `PyNcclCommunicator` class. CPU-side control message passing is handled via the `send obj` and `recv obj` methods. The intended behavior was for this interface to be exposed only to a private network using the IP address specified by the `--kv-ip` CLI parameter. The default behavior of PyTorch allows the `TCPStore` interface to listen on all interfaces, regardless of the provided IP address. **Recommendations** Update to vLLM version 0.8.5 or later to benefit from the fix that limits the `TCPStore` socket to the configured private interface.

**Name of the Vulnerable Software and Affected Versions** vLLM versions prior to 0.8.0 **Description** The issue is related to the outlines library used by vLLM for structured output, which has an optional cache for compiled grammars on the local filesystem. This cache is enabled by default. A malicious user can exploit this by sending multiple short decoding requests with unique schemas, causing the cache to grow and potentially leading to a Denial of Service if the filesystem runs out of space. The affected code is in the vllm/model executor/guided decoding/outlines logits processors.py file, which unconditionally uses the cache from outlines. The issue applies only to the V0 engine. **Recommendations** For versions prior to 0.8.0, update to version 0.8.0 to resolve the issue. As a temporary workaround, consider disabling the use of the outlines library or restricting access to the guided decoding backend key of the extra body field of the request to minimize the risk of exploitation.