CVE-2026-114055: Uncontrolled Resource Consumption in vLLM via Unvalidated Multimodal Kwargs

The vLLM framework serves as an open-source library for high-throughput Large Language Model (LLM) and Multimodal LLM (MLLM) serving. In versions ranging from 0.7.3 up to 0.30.x, the HTTP REST API endpoints—including OpenAI-compatible chat completions (/v1/chat/completions) and pooling endpoints—expose per-request parameters named mm_processor_kwargs and media_io_kwargs.

These request-level keyword dictionaries were designed to allow clients to customize preprocessing parameters for vision and audio inputs. However, because these inputs passed without validation from API entrypoints into backend preprocessing routines, callers could modify internal array construction parameters. The weakness is categorized as CWE-400 (Uncontrolled Resource Consumption).

The attack surface is accessible over the network to any client capable of sending JSON POST payloads to public or multi-tenant vLLM endpoints. No authentication or privileged access is required to exploit the flaw on default deployments.

The fundamental root cause is the implicit trust placed in client-supplied dictionaries during multimodal tensor initialization. When processing multimodal requests for models such as InternVL, Isaac, or H2OVL, vLLM routes user inputs to model-specific Hugging Face processors and custom image or video transformers.

Parameters such as vision_min_num_patches, patch_size, num_frames, crop boundaries, and sampling frame rates determine the dimensions of output tensors. When an attacker passes artificially inflated numbers within mm_processor_kwargs or media_io_kwargs (for example, setting vision_min_num_patches to several billion), the underlying preprocessing routines attempt to initialize multi-dimensional arrays matching those specifications.

Because vLLM did not enforce upper bounds or restrict parameter overrides, the application executes memory allocation calls corresponding to those extreme values. This rapidly exhausts host CPU memory or GPU VRAM, triggering unhandled memory allocation exceptions or OS-level Out-Of-Memory (OOM) killer signals that abruptly terminate the entire vLLM server process.

Prior to version 0.31.0, the protocol handlers in vllm/entrypoints/generate/base/protocol.py accepted mm_processor_kwargs and media_io_kwargs without inspecting their contents or verifying client authorization. The parameters were forwarded directly to backend model workers.

In patch commit 31f2e70cd3e403aaa471fb7fe3d33a7207aaf3cc (associated with Pull Request #58830), the maintainers implemented a default-deny control function named validate_request_mm_kwargs and introduced a command-line flag --trust-request-mm-kwargs which defaults to False.

# File: vllm/entrypoints/generate/base/protocol.py
 
def validate_request_mm_kwargs(
    *,
    mm_processor_kwargs: dict[str, Any] | None,
    media_io_kwargs: dict[str, dict[str, Any]] | None,
    trust_request_mm_kwargs: bool,
) -> None:
    """Reject untrusted per-request multimodal kwarg overrides."""
    if trust_request_mm_kwargs:
        return
 
    if mm_processor_kwargs:
        raise VLLMValidationError(
            "Per-request mm_processor_kwargs are disabled by default because "
            "they can change multimodal preprocessing resource usage. Start "
            "the server with --trust-request-mm-kwargs only when clients "
            "are trusted.",
            parameter="mm_processor_kwargs",
        )
    if media_io_kwargs:
        raise VLLMValidationError(
            "Per-request media_io_kwargs are disabled by default because "
            "they can change multimodal media loading resource usage. Start "
            "the server with --trust-request-mm-kwargs only when clients "
            "are trusted.",
            parameter="media_io_kwargs",
        )

By default, any attempt to include non-empty mm_processor_kwargs or media_io_kwargs in an API payload raises a VLLMValidationError, returning an HTTP 400 client error before any media processing or tensor allocation occurs.

Exploitation does not require bypasses of memory protection mechanisms or complex timing conditions. An attacker constructs a standard HTTP POST request targeted at the /v1/chat/completions endpoint of a vulnerable vLLM deployment.

The payload includes an image or video object along with a nested mm_processor_kwargs parameter containing extreme numeric values. An example JSON body constructed to trigger the vulnerability appears below:

{
  "model": "vllm-multimodal-model",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "Describe this image"},
        {"type": "image_url", "image_url": {"url": "https://example.com/test.jpg"}}
      ]
    }
  ],
  "mm_processor_kwargs": {
    "vision_min_num_patches": 3000000000
  }
}

Upon receiving this request, the server passes vision_min_num_patches: 3000000000 directly into the image processor constructor. Python's numerical calculation attempts to allocate host memory arrays proportional to 3 billion patches, immediately causing an unhandled memory exception or triggering the Linux OOM killer.

The overall impact is classified as High severity regarding Availability (CVSS 3.1 Score: 7.5, Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Successful exploitation triggers process termination, abruptly dropping all active inference requests connected to the instance.

In multi-tenant cloud environments or public AI API deployments, a single unauthenticated request can disrupt service for all users on the affected node. If vLLM is deployed without automated process restart managers (such as systemd or Kubernetes pod restart policies), the application remains down indefinitely.

Neither confidentiality nor integrity is affected. There is no indication that this flaw enables remote code execution or arbitrary memory read/write capability.

Organizations using vLLM should immediately upgrade to version 0.31.0 or later. This release enforces the default-deny policy for per-request multimodal kwargs.

> [!NOTE] > Ensure that system startup commands and configuration scripts do not pass the --trust-request-mm-kwargs flag unless the endpoint is deployed strictly within an isolated internal network serving verified, trusted clients.

For instances running legacy versions where an immediate upgrade is not feasible, security teams should deploy an API Gateway or Web Application Firewall (WAF) rule to strip or reject HTTP request bodies containing the mm_processor_kwargs or media_io_kwargs JSON keys.