vLLM: unbounded frame count in video/jpeg base64 data URLs crashes the server with OOM

Impact

The num_frames limit (default 32) that normally caps decoded video frames is not applied on the video/jpeg base64 data-URL path, so a single request carrying thousands of comma-separated JPEG frames is decoded in full into host memory. The serving process dies with an out-of-memory kill, taking down every model replica in that container and, on a node where the OOM killer picks badly, disturbing co-located processes. On a GPU node the cost is not the crash itself but the restart: weights have to be reloaded into HBM and any in-flight KV cache and queued requests are lost, so a cheap request buys minutes of dead accelerator time. Availability only — no data disclosure or corruption.

Who can reach it

Anyone who can send a multimodal completion request to the vLLM HTTP endpoint. The CVSS vector records PR:L, i.e. a low-privilege API credential, which in most fleets is any tenant holding a key; deployments that expose vLLM behind an unauthenticated internal gateway have no barrier at all.

What to do

Upgrade to vLLM 0.19.0 or later and restart each serving process; a rolling restart across replicas keeps the endpoint up but each restarted worker reloads model weights. Red Hat has shipped errata for AI Inference Server, RHEL AI 3 and OpenShift AI. No GPU node drain or reboot is required. If you cannot upgrade now, cap request body size at the ingress in front of vLLM.

References