Live › vulnerability › CVE-2026-116179
Go to dashboardvLLM versions from 0.18.0 before 0.31.0 let API clients override the video frame-count limit through media_io_kwargs. Setting num_frames to -1 with a large inline video makes the server decode every frame, which exhausts memory and crashes the API frontend.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-25 14:41 UTC. All times on this page are UTC.
Teams running a vLLM server that accepts video inputs from API clients, especially if that endpoint is reachable by users outside the team. Deployments that only serve text, or that sit behind trusted internal callers only, are at much lower risk.
No product ranges from the sources yet.
pip show vllm or python -c "import vllm; print(vllm.__version__)"; versions from 0.18.0 up to but not including 0.31.0 are affected.0.31.0 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
vLLM from 0.18.0 before 0.31.0 contains a resource exhaustion vulnerability that allows API clients to bypass the video/jpeg frame-count cap by overriding num_frames through media_io_kwargs. Attackers can set num_frames to -1 with a large inline video so VideoMediaIO.load_base64 decodes every frame, exhausting memory and crashing the API frontend.
This page as .md · .json · in your agent: get_signal("CVE-2026-116179")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.