CVE-2026-69147: vLLM: Request-selected PyNvVideoCodec GPU decode bypasses static VRAM reservation
vLLM is an inference and serving engine for large language models. Prior to 0.28.0, request bodies for Chat Completions and Responses can set mediaiokwargs.video.videobackend to pynvvideocodec, and MediaConnector.fetchvideo forwards that choice to VideoMediaIO even when startup configuration selected a software decoder. The engine's reservemmipcgpumemory logic budgets decoder memory only from static configuration, so the request-selected VIDEOLOADERREGISTRY backend can create a CUDA context, decoder surfaces, and decoded-frame allocations that were not removed from the engine's KV-cache budget. An attacker able to submit video requests to a video-capable GPU deployment with PyNvVideoCodec installed can exhaust shared GPU memory, causing request failures, worker crashes, or denial of service. The first release containing the fix is version 0.28.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
vLLMto a version that resolves this vulnerability.Fixed in 0.28.0
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service issue?
Deployments are exposed if they run a version prior to 0.28.0, serve video-capable GPU workloads, have PyNvVideoCodec installed, and allow an attacker to submit video requests.
What access does an attacker need to trigger the issue?
The attacker needs permission to submit video requests. They can select the pynvvideocodec backend through media_io_kwargs.video.video_backend in Chat Completions or Responses request bodies; no user interaction is required.
Is a software decoder startup configuration sufficient to prevent exploitation?
No. Before 0.28.0, a request can select pynvvideocodec even when startup configuration chose a software decoder, causing GPU decoder memory allocations outside the static VRAM reservation.
What is the operational impact of a successful attack?
An attacker can exhaust shared GPU memory, leading to request failures, worker crashes, or denial of service. The vulnerability does not indicate confidentiality or integrity impact.
What should be done if an immediate upgrade is not possible?
Restrict untrusted users from submitting video requests and avoid deployments where PyNvVideoCodec is installed for exposed video-capable GPU endpoints. Upgrade to vLLM 0.28.0 when possible.