---
id: "CVE-2026-114055"
kind: "vulnerability"
aliases: ["CVE-2026-114055", "GHSA-gx7p-2j49-hfq4"]
title: "vLLM : DoS via unvalidated mm_processor_kwargs in multimodal image processors (Isaac, InternVL, H2OVL, etc.)"
severity: "high"
cvss: 8.7
epss: 0.00343
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "vllm", "fixed": ["0.31.0"], "affected": ">= 0.7.3, < 0.31.0", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ai-tooling", "cwe-400", "multimodal", "openai-compatible-api", "python", "self-hosted", "vllm"]
not_affected_if: ["no-multimodal-models", "offline-llm-only", "vllm-0.31.0-or-later", "vllm-before-0.7.3"]
published_at: "2026-10-21T01:17:28+00:00"
first_seen_at: "2026-10-23T20:59:05+00:00"
updated_at: "2026-10-23T21:57:27+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-gx7p-2j49-hfq4", "first_seen_at": "2026-10-23T20:59:05+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114055", "first_seen_at": "2026-10-23T21:57:27+00:00"}]
---

# vLLM : DoS via unvalidated mm_processor_kwargs in multimodal image processors (Isaac, InternVL, H2OVL, etc.)

vLLM 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, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:vllm affected >= 0.7.3, < 0.31.0 fixed 0.31.0

## How to check

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

## Fix

Upgrade vllm to 0.31.0 or later. Patch referenced: https://github.com/vllm-project/vllm/pull/58830

## Timeline

- 2026-10-23T20:59:05+00:00 ghsa https://github.com/advisories/GHSA-gx7p-2j49-hfq4
- 2026-10-23T21:57:27+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-114055

## From the sources

## 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

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_