vLLM version 0.26.0 patches a medium-severity server-side request forgery (SSRF) and arbitrary local file read vulnerability in the multimodal processor for MiMoV2OmniForCausalLM, tracked as CVE-2026-73560 and GHSA-4hhp-h66f-j5j71. All vLLM versions below 0.26.0 are affected.
The flaw sits in `vllm/transformers_utils/processors/mimo_v2_omni.py`, where the `_fetch_image` method in MiMoV2OmniMultiModalProcessor issues raw `requests.get(...)` calls on user-supplied image and audio URL strings and opens local paths via `Image.open(...)` without the SSRF protections or `allowed_local_media_path` checks that MediaConnector was hardened with in three earlier advisories: GHSA-qh4c-xf7m-gxfc, GHSA-v359-jj2v-j536, and GHSA-pf3h-qjgv-vcpr. The advisory classifies the bug as the same class as those three prior vulnerabilities, in a code path the earlier patches missed.
When a user passes a URL or local-file string through `multi_modal_data` (for example, `LLM.generate(multi_modal_data={"image": "http://..."})`), the processor dispatches the unsanitized string without any URL-scheme allowlist, network-target allowlist, size cap, or local-path allowlist. The advisory states that the public OpenAI-compatible chat-completion path is protected, but library-level use such as `LLM.generate(multi_modal_data=...)`, batch processing, and other string-to-processor paths are not.
The vulnerability was reported by Ievgen Bondarenko.
ANALYSIS The recurring pattern here is notable: three prior advisories hardened MediaConnector against SSRF and local file reads, yet the MiMoV2OmniMultiModalProcessor code path was left unpatched, processing user-supplied strings through a parallel, unprotected sink. The exposure surface is narrower than a full API-level SSRF because the OpenAI-compatible serving endpoint is reportedly protected; the risk concentrates on teams running vLLM as a library, calling `LLM.generate` directly or using batch pipelines that pass raw media strings to the processor.
Red Hat recently published a technical guide on optimizing vLLM speculative decoding using FastMTP heads[2], a reminder of the framework's expanding footprint across production inference stacks. ◆ That growing adoption raises the stakes for each security patch cycle: more deployments mean more environments where an unpatched vLLM instance could expose internal network endpoints or local filesystem contents through crafted multimodal inputs.
Operators running vLLM below 0.26.0 with MiMoV2OmniForCausalLM and accepting user-supplied media strings should upgrade to 0.26.0.