vLLM EUVD-2026-109440

Exploitation requires a vLLM deployment (0.18.0 through before 0.31.0) that serves a video-capable multimodal model and accepts inline video/jpeg media, and that honors per-request media_io_kwargs - runtime media_io_kwargs support first shipped in stable 0.18.0, which is why earlier versions are unaffected. The concrete trigger is a request setting media_io_kwargs.video.num_frames to -1 (or an arbitrarily large positive value) together with a large inline video/jpeg payload, which bypasses the positive-num_frames frame cap in VideoMediaIO.load_base64. Limiting factors: the target must actually be configured as a video/multimodal server (a text-only vLLM instance is not exposed), and in fixed versions (>= 0.31.0) the attack is blocked unless the operator explicitly re-enables client overrides with --trust-request-mm-kwargs. The CVSS vector lists PR:N (no authentication), so any client able to reach the endpoint qualifies; where the endpoint sits behind authentication or a gateway, that access control limits the realistic attacker set.

This is a genuine but bounded operational risk, best characterized as a reliability/availability threat rather than a system-compromise emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity issue requiring no authentication per the vector, and impact is confined to availability (VA:H) with no confidentiality or integrity impact (VC:N/VI:N) - consistent with a CWE-770 uncontrolled resource consumption / denial-of-service flaw. The vuln.today decision label is 'this_week', indicating prioritized but not emergency remediation. No CISA KEV listing and no EPSS score were provided in the input, so there is no signal of active or probable widespread exploitation; status is therefore 'no public exploit identified at time of analysis'. The only exploitation evidence is the vendor/VulnCheck advisory noting the issue was reproduced internally on vLLM 0.19.1 - this is a confirmed reproduction report, not published public exploit code. A key nuance: although the CVSS vector says PR:N, real-world exploitation requires that the target actually serve a video-capable multimodal model and accept per-request media_io_kwargs, which materially narrows the exposed population below what the unauthenticated network vector alone implies. Net: a legitimately high-severity availability bug for affected multimodal deployments, but not a critical-impact or mass-exploitation priority - patch on the vendor's 'this_week' cadence.

An attacker (or careless client) with reach to a vLLM chat/completions endpoint backed by a video-capable multimodal model submits a large inline video/jpeg payload and sets media_io_kwargs.video.num_frames to -1, which selects the unlimited-frame branch of VideoMediaIO.load_base64. The server decodes and numpy.stacks every frame into a multi-gigabyte array before request validation rejects it, exhausting API-frontend memory/CPU and crashing or OOM-killing the serving process. No published exploit code is identified in the provided data; the flaw was reproduced by the reporter on vLLM 0.19.1 and the low attack complexity (AC:L) means crafting the malicious request is trivial.