CVE-2026-114055: vLLM 0.7.3 before 0.31.0 DoS via Unvalidated mm_processor_kwargs
Summary
API clients can supply arbitrary mmprocessorkwargs per request. vLLM forwards these values through the multimodal rendering and processing pipeline to Hugging Face and custom image/video processor constructors and calls. Resource-sensitive values such as image size, patch size, patch count, crop count, or frame count can therefore be controlled by a remote client.
For processors that upscale inputs, a single request can force an allocation large enough to terminate the API server or worker with an out-of-memory condition.
Affected Components
The per-request field was introduced in commit 041e29471671a3d43afedb6a749421d56ef4d3e7 and first shipped in v0.7.3. The generic forwarding path remains present in current main.
The Isaac path is a concrete high-amplification example:
- ChatCompletionRequest.mmprocessorkwargs - OnlineRenderer request extras - MMProcessorInputs.hfprocessormmkwargs - BaseMultiModalProcessor.info.gethfprocessor(hfprocessormmkwargs) - IsaacProcessingInfo.getimageprocessor(kwargs) - IsaacImageProcessor(kwargs) - processvisionforpatches()
Equivalent constructor forwarding exists in InternVL-derived processors, H2OVL, Step3VL, NemotronVL, and other multimodal processors. The issue is at the shared remote-input boundary and is not limited to a fixed model list.
Impact
- Availability: one request can exhaust CPU or GPU memory and terminate a shared service process. - Scope: all users of the affected service instance lose availability. - Authentication: vLLM's API key is optional, so deployments without an external authentication layer are remotely reachable without privileges.
Remediation
Reject non-empty per-request mmprocessorkwargs at every API-server request schema by default. Operators serving only trusted clients can explicitly opt in to the existing override behavior. Server-level --mm-processor-kwargs and offline LLM overrides remain available.
This shared boundary covers current and future multimodal processors instead of maintaining a model-specific list or a denylist that can miss custom processor arguments.
A patch for this was merged here: https://github.com/vllm-project/vllm/pull/58830
Other sources
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 mmprocessorkwargs. 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/vllmto a version that resolves this vulnerability.Fixed in 0.31.0 - Upgrade
Upgrade
vLLMto a version that resolves this vulnerability.Fixed in 0.31.0 - Configuration
Reject non-empty per-request mm_processor_kwargs at every API-server request; server-level --mm-processor-kwargs and offline LLM overrides remain available.
vLLM API server per-request mm_processor_kwargs = reject non-empty values
Event History
Frequently Asked Questions
Which deployments are exposed?
vLLM deployments running versions from 0.7.3 up to, but not including, 0.31.0 are affected when remote clients can submit requests that include multimodal processor parameters. The issue can exhaust memory and terminate a shared server.
Does exploitation require authentication or user interaction?
No. The listed vector is network-accessible, with low attack complexity, no privileges required, and no user interaction required.
What should be prioritized for remediation?
Upgrade affected vLLM installations to version 0.31.0 or later. The vulnerable behavior involves per-request mm_processor_kwargs that can control values such as image size, patch count, crop count, and frame count.