CVE-2026-115914 in vLLM
Summary
by MITRE • 10/26/2026
vLLM is an inference and serving engine for large language models. From 0.11.1 until 0.32.0, the DeepSeek-OCR, DeepSeek-OCR-2, and Unlimited-OCR image path allows a remote client that can reach the OpenAI-compatible API to submit a legal image whose normalized pixels sum to zero when that image is alone in its per-step encoder batch. _parse_and_validate_image_input returns no embedding, embed_multimodal propagates that value, and sanity_check_mm_encoder_outputs triggers a fatal assertion that shuts down the engine for all users. This issue is fixed in version 0.32.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified within vLLM versions ranging from 0.11.1 to 0.32.0 represents a significant availability risk targeting large language model inference engines that support multimodal inputs. As an open-source library designed for high-throughput and memory-efficient LLM serving, vLLM is frequently deployed in production environments where reliability is paramount. The specific flaw resides in the handling of image inputs processed by DeepSeek-OCR variants, including DeepSeek-OCR and Unlimited-OCR models. These components are responsible for converting visual data into embeddings that can be consumed by the language model. When a remote client with access to the OpenAI-compatible API endpoint submits an image where the normalized pixel values sum to zero, it triggers a critical failure in the internal validation logic. This scenario typically arises when an image is processed as the sole element within its per-step encoder batch, isolating the problematic input from other data that might otherwise mask or mitigate the anomaly during normalization processes.
Technically, the root cause lies in how _parse_and_validate_image_input handles edge cases involving zero-sum pixel arrays. Under normal operation, this function should return a valid embedding tensor representing the visual features of the image. However, due to insufficient validation checks for degenerate inputs where all normalized pixels equal zero or cancel out completely, the function returns no embedding object. This null result is then propagated through the embed_multimodal routine without raising an immediate exception or returning an error code that allows graceful degradation. Instead, the system proceeds to pass this empty state into sanity_check_mm_encoder_outputs. This validation layer expects a non-empty encoder output and contains a fatal assertion designed to catch programming errors during development. In a production environment, triggering such an assertion results in an unhandled crash of the Python process hosting the vLLM engine. Consequently, the entire inference service shuts down abruptly, rendering it unavailable for all concurrent users regardless of whether their requests were related to image processing or text-only queries.
The operational impact of this vulnerability is severe due to its direct effect on system availability and reliability. Because the crash terminates the main process rather than failing gracefully per-request, a single maliciously crafted request can cause a denial-of-service condition for all users connected to the vLLM instance. This aligns with Common Weakness Enumeration CWE-20 Improper Input Validation, as the software fails to adequately verify image data before processing it through critical inference pipelines. Furthermore, from an offensive security perspective, this vulnerability maps directly to MITRE ATT&CK technique T1499 Endpoint Denial of Service, specifically under sub-techniques involving application exhaustion or resource consumption via malformed inputs. Attackers can exploit this by sending a single crafted image payload over the network, requiring no authentication if the API endpoint is publicly accessible, thereby achieving remote code execution in terms of service disruption without needing elevated privileges on the host system.
Mitigation strategies must focus on both immediate patching and long-term architectural resilience. The primary remediation is to upgrade vLLM to version 0.32.0 or later, where this specific assertion failure has been addressed by developers who likely added robust checks for empty embeddings before they reach the sanity check stage. For environments unable to immediately update, implementing a reverse proxy with strict input validation can serve as an interim control layer. This intermediary should inspect incoming multimodal requests and reject payloads that exhibit characteristics of degenerate images, such as extremely low entropy or uniform pixel values indicative of zero-sum normalization artifacts. Additionally, deploying the vLLM service behind robust container orchestration platforms like Kubernetes allows for automatic restarts upon crash, minimizing downtime although it does not prevent the initial disruption. Long-term improvements should include integrating formal fuzzing tests into the CI/CD pipeline specifically targeting multimodal input parsers to detect similar edge cases before they reach production deployments.