CVE-2026-114055: vLLM : DoS via unvalidated mm_processor_kwargs in multimodal image processors (Isaac, InternVL, H2OVL, etc.)

vLLM accepts a per-request mm_processor_kwargs field, for example on ChatCompletionRequest. The server forwards it through the multimodal rendering path into the constructors and calls of Hugging Face and custom image or video processors. Values such as image size, patch size, patch count, crop count and frame count are therefore chosen by the client.

Processors that upscale their input turn a small request into a very large allocation. The advisory names the Isaac image processor (IsaacImageProcessor, process_vision_for_patches()) as a high-amplification example. InternVL-derived processors, H2OVL, Step3VL and NemotronVL forward kwargs the same way, so the flaw sits at the shared request boundary and not in one model.

The attacker needs network access to the API and nothing else. vLLM's API key is optional, so a deployment without an authenticating proxy is open to anonymous requests. The result is an out-of-memory crash of CPU or GPU memory that ends the process. Every user of that instance loses service. The CVSS vector is availability-only (A:H), with no confidentiality or integrity loss.

Affected: vllm from 0.7.3, where the per-request field first shipped, up to but not including 0.31.0. Deployments that serve a multimodal model through the OpenAI-compatible API server and are reachable by untrusted clients carry the most risk. Check the installed version:

pip show vllm

For container deployments, check the version inside the image you run.

Upgrade to vLLM 0.31.0.

pip install --upgrade "vllm>=0.31.0"

The fix (pull request 58830) rejects non-empty per-request mm_processor_kwargs and media_io_kwargs by default and raises a VLLMValidationError. Operators who serve only trusted clients can opt back in with --trust-request-mm-kwargs. Server-level --mm-processor-kwargs and offline LLM overrides still work. Do not turn on the opt-in flag for an internet-facing server. The sources give no other workaround, so until you upgrade, keep the API behind an authenticated gateway.

Look for API server or worker processes that were killed by the out-of-memory killer, or restarted, right after a multimodal request. In the request logs, search for chat completion bodies that contain an mm_processor_kwargs field with large size, patch, crop or frame values. Legitimate clients rarely set it. After the upgrade, requests that include the field fail with a validation error unless --trust-request-mm-kwargs is set.

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