Live › vulnerability › CVE-2026-114055
Go to dashboardvLLM forwards arbitrary per-request mm_processor_kwargs from API clients into multimodal image and video processor constructors, so resource-sensitive values like image size or frame count are client-controlled. A remote client can force an out-of-memory allocation that terminates the shared API server or worker process.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 20:59 UTC, 1h before NVD. All times on this page are UTC.
| Product |
|---|
| Ecosystem |
|---|
| Affected |
|---|
| Fixed in |
|---|
| vllm | pypi | >= 0.7.3, < 0.31.0 | 0.31.0 |
pip show vllm (affected if version is >= 0.7.3 and < 0.31.0)
Check whether API clients can send mm_processor_kwargs in chat completion requests
0.31.0 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
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_kwargsOnlineRenderer request extrasMMProcessorInputs.hf_processor_mm_kwargsBaseMultiModalProcessor.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.
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
This page as .md · .json · in your agent: get_signal("CVE-2026-114055")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.