Threat Advisory

PyNvVideoCodec GPU Decode Bypasses Static VRAM Reservation

Threat: Vulnerability
Targeted Region: Global
Targeted Sector: Technology & IT
Criticality: Medium
[subscribe_to_unlock_form]

EXECUTIVE SUMMARY:

CVE-2026-69147 is a medium-severity vulnerability affecting vllm versions < 0.28.0 with a CVSS score of 6.5 that affects vLLM deployments where PyNvVideoCodec is installed and usable, allowing an attacker to force frontend GPU decoding even when the engine did not reserve memory for that decoder during startup. This can potentially lead to request failures, worker crashes, or service-level denial of service by exhausting GPU memory that the engine assumed was available for weights, activations, or KV cache. The vulnerability arises from a split between request-time media decoding choices in the API server and startup-time memory budgeting in the engine worker, where an ordinary multimodal inference request can carry a backend override in the request body to reach the GPU decoder path without allocating GPU memory. To exploit this issue, an attacker must submit video requests that reach a video-capable model/path, which does not claim code execution, data disclosure, or SSRF. Suggested weaknesses are CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-400 (Uncontrolled Resource Consumption). A suggested fix is to reject request-level media_io_kwargs.video.video_backend="pynvvideocodec" unless the static server configuration already selected PyNvVideoCodec and reserved its decoder/CUDA-context budget.

RECOMMENDATION:

We recommend you to update vLLM to version 0.28.0.[/subscribe_to_unlock_form]

EXECUTIVE SUMMARY:

CVE-2026-69147 is a medium-severity vulnerability affecting vllm versions < 0.28.0 with a CVSS score of 6.5 that affects vLLM deployments where PyNvVideoCodec is installed and usable, allowing an attacker to force frontend GPU decoding even when the engine did not reserve memory for that decoder during startup. This can potentially lead to request failures, worker crashes, or service-level denial of service by exhausting GPU memory that the engine assumed was available for weights, activations, or KV cache. The vulnerability arises from a split between request-time media decoding choices in the API server and startup-time memory budgeting in the engine worker, where an ordinary multimodal inference request can carry a backend override in the request body to reach the GPU decoder path without allocating GPU memory. To exploit this issue, an attacker must submit video requests that reach a video-capable model/path, which does not claim code execution, data disclosure, or SSRF. Suggested weaknesses are CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-400 (Uncontrolled Resource Consumption). A suggested fix is to reject request-level media_io_kwargs.video.video_backend="pynvvideocodec" unless the static server configuration already selected PyNvVideoCodec and reserved its decoder/CUDA-context budget.

RECOMMENDATION:

We recommend you to update vLLM to version 0.28.0.[emaillocker id="1283"]

REFERENCES:

The following reports contain further technical details:

[/emaillocker]
crossmenu