GHSA-gx7p-2j49-hfq4 CVE-2026-114055
vLLM : DoS via unvalidated mm_processor_kwargs in multimodal image processors (Isaac, InternVL, H2OVL, etc.)
- Severity
- 8.7 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.42%
- Chance of exploitation in the next 30 days. Higher than 36.32% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-400 Uncontrolled Resource Consumption
- Fix
0.31.0- Upgrade vllm to this version or later
Description
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_kwargsOnlineRendererrequest extrasMMProcessorInputs.hf_processor_mm_kwargsBaseMultiModalProcessor.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
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| vllm | >= 0.7.3, < 0.31.0 |
0.31.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
vllm PyPI → 0.31.0
- pip
pip install --upgrade "vllm>=0.31.0"- poetry
poetry add "vllm>=0.31.0"- uv
uv add "vllm>=0.31.0"
Severity breakdown
CVSS 4.0 8.7
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
- Exploit maturity
- Not defined
- Scope
- X
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-400: Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource.
How to prevent it
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Implementation: Ensure that all failures in resource allocation place the system into a safe posture.
References
Advisories
Packages
Other links
- github.com/vllm-project/vllm/security/advisories/GHSA-gx7p-2j49-hfq4
- github.com/vllm-project/vllm/pull/58830
- github.com/vllm-project/vllm/commit/31f2e70cd3e403aaa471fb7fe3d33a7207aaf3cc
- github.com/vllm-project/vllm/releases/tag/v0.31.0
- vulncheck.com/advisories/vllm-0.7.3-before-0.31.0-dos-via-unvalidated-mm-processor…
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-8397-8qf6-f2gm vLLM: Phi-4 multimodal audio encoder materializes and retains full attention matrices: a single max-length audio OOM-crashes the vLLM engine | Medium | Also affects vllm |
| GHSA-x567-49g5-p4cf vLLM: Responses API bypasses trust_request_chat_template for chat_template_kwargs | Medium | Also affects vllm |
| GHSA-vvpg-rrww-wpmh vLLM: Permissive default CORS origins allow cross-origin requests to the vLLM HTTP server | Medium | Also affects vllm |
| GHSA-q97c-p368-75c4 vLLM: Out-of-vocabulary prompt token id passes input validation and triggers a CUDA device-side assert (engine crash / DoS) | Medium | Also affects vllm |
| GHSA-h3rc-j82p-2c3h vLLM: Untrusted EPS inputs can trigger denial of service or Ghostscript RCE | High | Also affects vllm |
| GHSA-gq5q-89c7-vhvx vLLM DeepSeek-OCR image processing vulnerable to denial of service | Medium | Also affects vllm |
| GHSA-6757-hggm-hp2w vLLM: Public multimodal SHM handle forgery reaches worker-side `pickle.loads()` with insecure serialization disabled | High | Also affects vllm |
| GHSA-542m-9234-8gvf vLLM: DoS via unbounded chat_template Jinja2 rendering exhausts the renderer thread pool | Medium | Also affects vllm |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor