What happened
vLLM's VideoMediaIO.load_base64 frame-count protection could be bypassed by overriding VideoMediaIO.num_frames through request-level media_io_kwargs.video. Setting num_frames to -1 selects the unlimited branch, which splits and decodes every frame, so a large inline video/jpeg can make the API frontend allocate a multi-gigabyte frame array before later validation rejects it (CWE-400, CVSS 7.5).
Why it matters
The resource consumption happens in the API frontend before engine validation, so a single chat request can consume excessive memory and CPU and crash or OOM-kill the serving process on a video-capable multimodal deployment.
Attack vector
Submit a large inline video/jpeg with media_io_kwargs.video.num_frames = -1 to force decoding of every frame.
Affected systems
vLLM >= 0.18.0, < 0.31.0 (video/jpeg MediaIO path).
Mitigation
Upgrade to vLLM 0.31.0 (PR #58830 rejects per-request media_io_kwargs by default; opt in with --trust-request-mm-kwargs only for trusted clients).