CVE-2026-114055 in vLLM
Summary
by MITRE • 10/22/2026
vLLM from 0.7.3 before 0.31.0 contains an uncontrolled resource consumption vulnerability that allows remote clients to control multimodal processor parameters by supplying per-request mm_processor_kwargs. Attackers can set large image size, patch count, crop count, or frame count values in Isaac, InternVL, H2OVL, and other processors to exhaust memory and terminate the shared server.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified within vLLM versions prior to 0.31.0 represents a critical uncontrolled resource consumption flaw that stems from insufficient validation of input parameters in multimodal processing pipelines. This security issue specifically affects the handling of per-request mm_processor_kwargs, which are configuration arguments passed by remote clients during inference requests. In modern large language model serving frameworks like vLLM, multimodal processors are responsible for transforming raw media inputs such as images and videos into token embeddings that can be processed by the underlying transformer models. The architectural design allows these processors to accept dynamic parameters on a per-request basis to optimize performance or handle specific data formats. However, in versions from 0.7.3 up to but not including 0.31.0, this flexibility is exploited due to a lack of rigorous bounds checking and resource allocation limits for critical image processing metrics.
The technical root cause lies in the ability of an authenticated or unauthenticated remote attacker to inject excessively large values into parameters such as image size, patch count, crop count, or frame count when interacting with specific multimodal processors including Isaac, InternVL, and H2OVL. These parameters directly dictate how much memory is allocated for tensor operations during the preprocessing phase. When an attacker supplies a request containing massive dimensions or high counts of patches and frames, the system attempts to allocate corresponding amounts of GPU or CPU memory without verifying whether such allocation is feasible within the server's available resources. This leads to immediate and severe memory exhaustion as the processor tries to instantiate large intermediate tensors that far exceed normal operational thresholds. The vulnerability effectively turns a standard inference request into a denial-of-service vector by forcing the system to consume all available computational resources in an attempt to process the malformed input.
The operational impact of this vulnerability is significant, primarily manifesting as a complete service disruption for shared vLLM deployments. Since these servers often handle multiple concurrent requests from various users or applications, the memory exhaustion caused by a single malicious request can crash the entire server instance rather than just failing that specific inference job. This results in a denial-of-service condition where legitimate users are unable to access the model services hosted on the affected system. The severity is compounded by the fact that many enterprise deployments rely on vLLM for high-throughput, low-latency serving of multimodal models, making availability a critical requirement. An attacker can trigger this state repeatedly or with minimal effort, leading to sustained downtime and potential data loss if persistent storage mechanisms are also impacted by the abrupt termination of processes.
From a classification perspective, this vulnerability aligns closely with CWE-400 Uncontrolled Resource Consumption, as it involves the failure to properly restrict resource allocation in response to external input. It is further categorized under CWE-770 Allocation of Resources Without Limits or Throttling, highlighting the absence of safeguards against excessive consumption. In terms of offensive security frameworks, this attack vector corresponds to MITRE ATT&CK technique T1498 Network Denial of Service, specifically sub-technique T1498.002 Resource Exhaustion via Flood Attacks, although in this context it is achieved through resource-intensive parameter manipulation rather than simple traffic flooding. The exploitation requires the ability to send crafted HTTP or gRPC requests containing the malicious mm_processor_kwargs, which may be possible depending on the authentication and network exposure of the vLLM endpoint.
Mitigation strategies must focus on both immediate patching and architectural hardening. The primary remediation is to upgrade the vLLM installation to version 0.31.0 or later, where developers have implemented stricter validation logic for multimodal processor parameters. Until an upgrade can be performed, administrators should implement network-level controls such as rate limiting and request size restrictions at the reverse proxy or load balancer layer to prevent excessively large payloads from reaching the application server. Additionally, configuring container resource limits using tools like Docker or Kubernetes can help contain the impact of a successful exploitation attempt by capping the maximum memory usage per pod, thereby preventing the crash of the entire host node. Input validation should also be enforced at the API gateway level to reject requests with parameter values that exceed predefined safe thresholds for image dimensions and patch counts, ensuring that only reasonable inference parameters are processed by the vulnerable components.