CVE-2026-116179 in vLLM
Summary
by MITRE • 10/25/2026
vLLM from 0.18.0 before 0.31.0 contains a resource exhaustion vulnerability that allows API clients to bypass the video/jpeg frame-count cap by overriding num_frames through media_io_kwargs. Attackers can set num_frames to -1 with a large inline video so VideoMediaIO.load_base64 decodes every frame, exhausting memory and crashing the API frontend.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in vLLM versions prior to 0.31.0 represents a critical resource exhaustion flaw within the media processing subsystem, specifically affecting how video frames are handled during inference requests. This issue stems from an insufficient validation mechanism when parsing input parameters for multimedia content. The core of the problem lies in the interaction between the API client and the internal VideoMediaIO component, where attackers can manipulate the num_frames parameter via the media_io_kwargs dictionary to override intended safety limits designed by developers.
In a secure implementation, applications typically enforce strict caps on resource consumption to prevent denial-of-service conditions. In this case, vLLM includes safeguards such as frame-count caps to limit memory usage during video processing. However, due to improper input validation and parameter handling, an authenticated or unauthenticated attacker depending on the deployment configuration can bypass these controls by explicitly setting num_frames to a negative value, specifically -1. This manipulation signals the underlying decoding logic to process all available frames rather than adhering to any predefined limit.
When combined with large inline video data embedded in the request payload, this override triggers VideoMediaIO.load_base64 to decode every single frame of the provided media stream without restriction. The consequence is a rapid and uncontrolled allocation of system memory as each decoded frame consumes significant RAM resources. This behavior directly leads to resource exhaustion on the host machine running the vLLM service.
The operational impact of this vulnerability is severe, resulting in a denial-of-service condition for both the targeted instance and potentially other services sharing the same infrastructure. As memory usage spikes uncontrollably, the API frontend process may crash or become unresponsive due to out-of-memory errors. This disrupts availability for legitimate users attempting to access inference capabilities through the vLLM interface. The attack vector is relatively straightforward, requiring only a crafted HTTP request with modified parameters and substantial video data embedded within it.
From a classification perspective, this vulnerability aligns with CWE-400, which covers uncontrolled resource consumption, as well as CWE-787, regarding out-of-bounds write if the memory corruption extends beyond allocated buffers during decoding processes. In terms of adversarial tactics, this behavior corresponds to ATT&CK technique T1496, Resource Hijacking, where attackers leverage compromised or misconfigured resources to cause service degradation or exhaustion for denial-of-service purposes.
Mitigation strategies should focus on immediate patching and defensive configuration changes. The primary remediation is upgrading vLLM to version 0.31.0 or later, where the developers have addressed this input validation flaw by enforcing strict bounds checking on frame count parameters regardless of user-supplied values. For environments unable to upgrade immediately, implementing a reverse proxy with rate limiting and payload size restrictions can help mitigate the impact by blocking excessively large video payloads before they reach the application layer. Additionally, configuring container resource limits such as memory constraints in Kubernetes or Docker deployments ensures that even if an attack succeeds, it will be contained within defined boundaries rather than crashing the entire host system.