CVE-2026-69147: vLLM GPU Memory Exhaustion DOS Vulnerability

CVE-2026-69147 Overview

CVE-2026-69147 is a resource exhaustion vulnerability [CWE-400] in vLLM, an inference and serving engine for large language models. Versions prior to 0.28.0 allow clients to override the video decoder backend at request time by setting media_io_kwargs.video.video_backend to pynvvideocodec. The MediaConnector.fetch_video path forwards that request-level choice to VideoMediaIO even when startup configuration selected a software decoder. Because the engine's _reserve_mm_ipc_gpu_memory logic budgets decoder memory only from static configuration, the request-selected backend allocates CUDA context, decoder surfaces, and decoded frames outside the KV-cache budget. An authenticated attacker can exhaust shared GPU memory on video-capable deployments with PyNvVideoCodec installed.

Critical Impact
Authenticated attackers submitting crafted video requests can exhaust GPU VRAM, causing request failures, worker crashes, and denial of service across the inference deployment.

Affected Products

vLLM versions prior to 0.28.0
Video-capable GPU deployments with PyNvVideoCodec installed
Multi-tenant inference services exposing Chat Completions or Responses APIs

Discovery Timeline

2026-09-16 - CVE-2026-69147 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-69147

Vulnerability Analysis

The vulnerability affects vLLM's multimodal request handling pipeline. Operators configure video decoder backends at engine startup, and _reserve_mm_ipc_gpu_memory pre-reserves GPU memory based on that static configuration. This reservation carves out VRAM for CUDA context creation, decoder surfaces, and decoded frame buffers, leaving the remaining VRAM as the KV-cache budget.

The flaw stems from MediaConnector.fetch_video honoring media_io_kwargs.video.video_backend from incoming request bodies. When a request selects pynvvideocodec, VideoMediaIO instantiates the GPU-backed decoder even if startup configuration chose a software decoder. No corresponding VRAM reservation exists, so the resulting CUDA context and decoder surfaces consume memory that the engine has already committed to KV-cache and model weights.

Root Cause

The root cause is trust boundary confusion between startup-time configuration and request-time parameters. The VIDEO_LOADER_REGISTRY lookup treats the request-supplied backend name as authoritative without checking whether that backend requires VRAM reservation. A single PYNVVIDEOCODEC_CUDA_CONTEXT_BYTES allocation is roughly 1.8 GiB on H100, which is large enough to destabilize workers when unaccounted for.

Attack Vector

An attacker with API access submits a Chat Completions or Responses request containing a video input and media_io_kwargs overriding the video backend to pynvvideocodec. The worker allocates a CUDA context and decoder surfaces outside the reserved budget. Repeating this pattern, or submitting concurrent requests, exhausts shared GPU memory and crashes workers.

python

# Patch: introduce GPU_VIDEO_BACKENDS allow-list to block request-level
# selection of backends that require startup-time VRAM reservation
# vllm/multimodal/video.py
PYNVVIDEOCODEC_CUDA_CONTEXT_BYTES = int(1.8 * 1024 * MiB_bytes)

# Video backends that allocate GPU VRAM (decoder surfaces, CUDA context)
# and therefore require startup-time memory reservation via
# _reserve_mm_ipc_gpu_memory. Request-level media_io_kwargs must not be
# allowed to select these backends unless the static config already
# reserved the corresponding budget.
GPU_VIDEO_BACKENDS: frozenset[str] = frozenset({PYNVVIDEOCODEC_VIDEO_BACKEND})

Source: vLLM commit 283893c

Detection Methods for CVE-2026-69147

Indicators of Compromise

Chat Completions or Responses requests containing media_io_kwargs.video.video_backend set to pynvvideocodec when the engine was started with a software decoder.
CUDA out-of-memory errors, worker process crashes, or unexpected KV-cache eviction on vLLM inference nodes handling video inputs.
Sudden drops in served request throughput correlated with video-bearing requests from a single client or API key.

Detection Strategies

Inspect API gateway or reverse-proxy logs for media_io_kwargs fields in request bodies and alert when video_backend is overridden.
Correlate vLLM worker restart events with GPU memory saturation metrics from nvidia-smi or DCGM exporters.
Baseline normal per-tenant GPU memory consumption and flag deviations tied to video request bursts.

Monitoring Recommendations

Continuously export GPU memory utilization, KV-cache fill, and worker restart counters to a central telemetry pipeline.
Enable structured request logging in front of vLLM to preserve full request bodies for forensic review of multimodal parameters.
Track vLLM package versions across GPU nodes to identify hosts still running releases prior to 0.28.0.

How to Mitigate CVE-2026-69147

Immediate Actions Required

Upgrade vLLM to version 0.28.0 or later, which introduces the GPU_VIDEO_BACKENDS allow-list and blocks request-level selection of GPU-backed video decoders.
Restrict API access to authenticated, trusted clients and rate-limit multimodal video endpoints.
Audit existing deployments for the presence of PyNvVideoCodec on hosts that do not require GPU video decoding and remove it where unnecessary.

Patch Information

The fix is included in vLLM 0.28.0. Review GitHub Security Advisory GHSA-8pw2-6jv3-mj5j and Pull Request #47259 for the full change set. The fix adds a _requires_gpu map to the video loader registry and rejects request-level selection of GPU backends that were not pre-reserved at startup.

Workarounds

Strip media_io_kwargs from inbound requests at an API gateway or reverse proxy until upgrade is complete.
Uninstall PyNvVideoCodec on nodes where GPU video decoding is not required so the backend cannot be selected at runtime.
Deploy per-tenant quotas and concurrency limits on video-bearing requests to slow memory exhaustion attempts.

bash

# Example NGINX snippet to reject requests overriding the video backend
location /v1/ {
    if ($request_body ~* "media_io_kwargs") {
        return 400 "media_io_kwargs override not permitted";
    }
    proxy_pass http://vllm_backend;
}

# Upgrade vLLM to the patched release
pip install --upgrade "vllm>=0.28.0"