CVE-2026-69147: vLLM: Request-selected PyNvVideoCodec GPU decode bypasses static VRAM reservation
Current vLLM main lets an inference request choose the PyNvVideoCodec GPU video decoder through media_io_kwargs.video.video_backend, but engine GPU memory reservation is computed only from static startup configuration and VLLM_VIDEO_LOADER_BACKEND. If the server starts with the default OpenCV/software backend and no --mm-ipc-gpu-memory-gb budget, a client can still route a video request into the PyNvVideoCodec path after startup, causing frontend CUDA-context, decoder-surface, and decoded-frame GPU allocations that were not carved out of the engine KV-cache budget.
References
- github.com/advisories/GHSA-8pw2-6jv3-mj5j
- github.com/vllm-project/vllm/commit/283893c72292ede38d277e3cd2b9b64c3e4f1dda
- github.com/vllm-project/vllm/commit/ba22152096b2484faa3579624a253d54804d876d
- github.com/vllm-project/vllm/pull/47259
- github.com/vllm-project/vllm/releases/tag/v0.25.0
- github.com/vllm-project/vllm/security/advisories/GHSA-8pw2-6jv3-mj5j
- nvd.nist.gov/vuln/detail/CVE-2026-69147
Code Behaviors & Features
Detect and mitigate CVE-2026-69147 with GitLab Dependency Scanning
Secure your software supply chain by verifying that all open source dependencies used in your projects contain no disclosed vulnerabilities. Dependency Scanning using SBOM also detects vulnerabilities from proprietary advisories that this site does not include. Learn more about Dependency Scanning using SBOM →