The vulnerability is that vLLM versions 0.24.0 through 0.30.0 allow an attacker to specify unbounded max_frames and fps values in media_io_kwargs for the Qwen2VLVideoBackend and Qwen3VLVideoBackend when calling the /tokenize endpoint. This lack of a server‑side ceiling lets an unauthenticated caller trigger the decoder to process every attacker‑controlled video frame, consuming excessive frontend memory and possibly causing the API process to terminate before it can complete scheduling or admission control. The result is a denial‑of‑service condition, which is consistent with CWE‑770 (Uncontrolled Resource Consumption).

Affected vendors and products: vllm‑project’s vllm inference engine. The issue is present in releases 0.24.0, 0.24.1, …, up to but not including 0.30.0; it was fixed with the release of v0.30.0. The Rust‑based frontend is not vulnerable because it rejects media_io_kwargs. Users running the Python or standard vllm frontends and deploying any of the affected Qwen2VLVideoBackend or Qwen3VLVideoBackend backends are at risk unless they upgrade.

The CVSS v3.1 score is 5.3, indicating moderate severity. No EPSS data is published, so the probability of exploitation is uncertain, and the vulnerability is not listed in CISA’s KEV catalog. An attacker can exploit the flaw simply by issuing an unauthenticated request to /tokenize with tailored media_io_kwargs values, making the vulnerability highly likely to be used if the service is exposed. The lack of user authentication and the direct nature of the endpoint make the attack vector straightforward. Even without authentication, the endpoint exposes a remote execution path that can drain resources in a way that could lead to process termination and service disruption.