One request can crash a vLLM server, advisory warns

A security advisory published on 23 October 2026 describes a denial-of-service flaw in vLLM, the open-source engine widely used to serve large language models. According to the advisory, GHSA-gx7p-2j49-hfq4, tracked as CVE-2026-114055, a single crafted request can exhaust CPU or GPU memory and terminate a shared service process, cutting off every user of that instance.

The problem lies in a per-request field called mm_processor_kwargs, which carries extra settings for multimodal processing, the handling of images and video alongside text. The advisory says API clients can supply arbitrary values in that field, and vLLM forwards them through the rendering and processing pipeline into Hugging Face and custom image and video processor constructors without validation.

That matters because the settings in question control how much work the server does. The advisory lists image size, patch size, patch count, crop count and frame count as resource-sensitive values that a remote client can therefore set. For processors that upscale their inputs, it says, one request can force an allocation large enough to kill the API server or a worker with an out-of-memory condition.

The advisory names the Isaac image processing path as a concrete high-amplification example, tracing the value from a chat completion request through the online renderer, the multimodal processor information class and the Isaac image processor into the vision patching function. It stresses that the issue is not confined to one model. Equivalent constructor forwarding exists in InternVL-derived processors, H2OVL, Step3VL, NemotronVL and others, and the advisory says the weakness sits at the shared boundary where remote input enters the system rather than in any fixed list of models.

The exposure is long-standing. According to the advisory, the per-request field was introduced in a specific commit and first shipped in version 0.7.3, and the generic forwarding path remains present in the current main branch. The affected package is the pip distribution of vllm.

Authentication offers limited protection. The advisory notes that vLLM's API key is optional, so deployments without an external authentication layer are remotely reachable without privileges. Any user able to send a completion request to such a server can trigger the condition.

The recommended fix is to reject non-empty per-request mm_processor_kwargs at every API-server request schema by default. The advisory says operators who serve only trusted clients can explicitly opt in to the existing override behaviour, and that server-level configuration through the --mm-processor-kwargs flag and offline overrides through the LLM interface remain available. The reasoning given is that closing the shared boundary covers current and future multimodal processors, rather than maintaining a model-specific allowlist or a denylist that could miss custom processor arguments.

A patch has been merged into the vLLM project, the advisory says, pointing to pull request 58830 in the vllm-project repository.

The pattern is a familiar one for teams running AI infrastructure: a convenience feature that lets callers tune behaviour becomes an availability risk once the caller is untrusted. Operators running multimodal models on vLLM, particularly those exposing an endpoint without a separate authentication layer in front of it, should check which version they are on and whether per-request processor overrides are accepted.