vllm: Frame-count cap bypass in VideoMediaIO.load_base64 for video/jpeg via media_io_kwargs.video.num_frames

Summary

The frame-count protection for inline video/jpeg data could be bypassed by overriding VideoMediaIO.num_frames through request-level media_io_kwargs. Setting num_frames to -1 selects the unlimited branch, which splits and decodes every frame. A large inline video can therefore make the API frontend allocate a multi-gigabyte frame array before later request validation rejects it.

The report confirmed this on vLLM 0.19.1. Runtime media_io_kwargs support first shipped in stable v0.18.0.

Affected code

For video/jpeg, VideoMediaIO.load_base64 limits frames when num_frames is positive, rejects zero, and otherwise splits the full input. The request's media_io_kwargs.video values were passed to VideoMediaIO without restricting num_frames, allowing a client override of -1 or an arbitrarily large positive value.

The decoded JPEG frames are individually loaded and then combined with numpy.stack, so an oversized request can consume substantial API-server memory before the engine processes it.

Impact

A client able to call the chat endpoint could submit a large inline video/jpeg payload and cause excessive memory and CPU use in the API frontend. The reported deployment used a video-capable multimodal model. The issue could crash or OOM-kill the serving process.

Fix

PR #58830 rejects non-empty per-request media_io_kwargs by default, preventing clients from overriding the server's video decoder settings. Deployments that explicitly trust their API clients can opt in with --trust-request-mm-kwargs.