GHSA-gx7p-2j49-hfq4: High severity pip/vllm vulnerability
Summary
API clients can supply arbitrary mmprocessorkwargs 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.mmprocessorkwargs - OnlineRenderer request extras - MMProcessorInputs.hfprocessormmkwargs - BaseMultiModalProcessor.info.gethfprocessor(hfprocessormmkwargs) - IsaacProcessingInfo.getimageprocessor(kwargs) - IsaacImageProcessor(kwargs) - processvisionforpatches()
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 mmprocessorkwargs 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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/vllmto a version that resolves this vulnerability.Fixed in 0.31.0 - Configuration
Reject non-empty per-request mm_processor_kwargs at every API-server request. Server-level --mm-processor-kwargs and offline LLM overrides remain available.
mm_processor_kwargs = reject non-empty values
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
API deployments that accept client-controlled ChatCompletionRequest values are exposed if they permit mm_processor_kwargs to be supplied per request. The affected field first shipped in vLLM v0.7.3, and the generic forwarding path remains in current main.
What does an attacker need to exploit it?
An attacker needs network access to the API endpoint and does not need privileges or user interaction. They can submit resource-sensitive multimodal processor parameters, such as image size, patch count, crop count, or frame count, in a request.
What is the likely impact of a successful request?
A request can cause image or video processing to allocate enough memory to terminate the API server or worker with an out-of-memory condition. The described impact is denial of service; no confidentiality or integrity impact is stated.
Which processor paths are known to amplify the issue?
The Isaac processor path is identified as a concrete high-amplification example, reaching IsaacImageProcessor and process_vision_for_patches(). Equivalent constructor forwarding is also stated to exist in InternVL-derived processors.