Project Subscriptions
No data.
No advisories yet.
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Wed, 16 Sep 2026 19:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Wed, 16 Sep 2026 18:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | vLLM: Request-selected PyNvVideoCodec GPU decode bypasses static VRAM reservation | |
| Weaknesses | CWE-400 CWE-770 |
|
| References |
| |
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: GitHub_M
Published:
Updated: 2026-09-16T18:37:14.118Z
Reserved: 2026-08-03T15:20:30.218Z
Link: CVE-2026-69147
Updated: 2026-09-16T18:36:52.431Z
Status : Received
Published: 2026-09-16T18:17:11.770
Modified: 2026-09-16T19:17:26.113
Link: CVE-2026-69147
No data.
OpenCVE Enrichment
No data.