vLLM: DoS via unvalidated mm_processor_kwargs in multimodal image processors (Isaac, InternVL, H2OVL…
vLLM
More for vLLM RSS feed for vLLM
- Severity
- High, CVSS 7.5
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Record
- CVE-2026-114055
- Affects
- vLLM
- Known exploited
- Not listed in the CISA Known Exploited Vulnerabilities catalog
- Published
- Record first published by the source
- October 23, 2026
- Source last modified
- October 23, 2026
Description
Summary
API clients can supply arbitrary mm_processor_kwargs 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.mm_processor_kwargs
- OnlineRenderer request extras
- MMProcessorInputs.hf_processor_mm_kwargs
- BaseMultiModalProcessor.info.get_hf_processor(**hf_processor_mm_kwargs)
- IsaacProcessingInfo.get_image_processor(**kwargs)
- IsaacImageProcessor(**kwargs)
- process_vision_for_patches()
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 mm_processor_kwargs 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
Description quoted from the NVD record.
Who is affected
vLLM is software that runs AI language models and answers requests sent to it by other programs. This flaw affects versions 0.7.3 and later when they handle images or video. A request can include settings for the part that prepares images and video, such as image size or frame count, and vLLM passes them on without checking. One request can use up the server's memory and shut it down, so everyone using that service loses access. vLLM's API key (a password programs use to connect) is optional, so setups without an extra login layer can be attacked by anyone who can reach them. This flaw is rated High.
What to do
- Find out who runs vLLM for your organization: the person who installed it, or the IT provider or vendor who manages it for you.
- If you run it yourself, check which version you have. Versions
0.7.3and later are affected. - No fixed version is named for this flaw yet, so check the vendor advisory linked on this page for a fixed release and install it as soon as it is available.
- If an IT provider or vendor runs vLLM for you, send them this advisory and ask when the update will be done.
Analysis written from the source record as of October 23, 2026 and reviewed before publishing.