vllm-project vLLM up to 0.27.x Video Decoder MediaConnector.fetch_video media_io_kwargs.video.video_backend allocation of resources

Summaryinfo

A vulnerability has been found in vllm-project vLLM up to 0.27.x and classified as problematic. Impacted is the function MediaConnector.fetch_video of the component Video Decoder. Performing a manipulation of the argument media_io_kwargs.video.video_backend results in allocation of resources. This vulnerability is cataloged as CVE-2026-69147. It is possible to initiate the attack remotely. There is no exploit available. The affected component should be upgraded.

Detailsinfo

A vulnerability was found in vllm-project vLLM up to 0.27.x. It has been classified as problematic. This affects the function MediaConnector.fetch_video of the component Video Decoder. The manipulation of the argument media_io_kwargs.video.video_backend with an unknown input leads to a allocation of resources vulnerability. CWE is classifying the issue as CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. This is going to have an impact on availability. The summary by CVE is:

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 media_io_kwargs.video.video_backend to pynvvideocodec, and MediaConnector.fetch_video forwards that choice to VideoMediaIO even when startup configuration selected a software decoder. The engine's _reserve_mm_ipc_gpu_memory logic budgets decoder memory only from static configuration, so the request-selected VIDEO_LOADER_REGISTRY 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.

It is possible to read the advisory at github.com. This vulnerability is uniquely identified as CVE-2026-69147 since 08/03/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1499 according to MITRE ATT&CK.

Upgrading to version 0.28.0 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• vllm-project

Name

• vLLM

Version

• 0.1
• 0.2
• 0.3
• 0.4
• 0.5
• 0.6
• 0.7
• 0.8
• 0.9
• 0.10
• 0.11
• 0.12
• 0.13
• 0.14
• 0.15
• 0.16
• 0.17
• 0.18
• 0.19
• 0.20
• 0.21
• 0.22
• 0.23
• 0.24
• 0.25
• 0.26
• 0.27

Website

• Product: https://github.com/vllm-project/vllm/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion