CVE-2026-78684: vLLM DeepStream GPU Backend DOS Vulnerability

CVE-2026-78684 Overview

CVE-2026-78684 affects vLLM versions before 0.27.0, an open-source library for large language model (LLM) inference and serving. The vulnerability stems from improper classification of NVIDIA DeepStream as a GPU backend and missing pixel-limit enforcement in the video decode path. Unauthenticated attackers can activate DeepStream at request time to initialize the process-wide GPU decode pool. Attackers then submit video payloads that bypass resource controls, causing partial denial of service (DoS) for concurrent inference requests. The flaw is tracked under CWE-400: Uncontrolled Resource Consumption.

Critical Impact

Remote unauthenticated attackers can degrade availability of vLLM inference endpoints by exhausting shared GPU decode resources, disrupting concurrent request processing.

Affected Products

• vLLM versions prior to 0.27.0
• Deployments exposing vLLM inference endpoints with video/multimodal input support
• Linux x86-64 hosts using the DeepStream (NVDEC) GPU video-decode backend

Discovery Timeline

• 2026-08-25 - CVE-2026-78684 published to NVD
• 2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-78684

Vulnerability Analysis

vLLM supports multimodal inference workloads that include video inputs decoded through GPU-accelerated backends. In versions before 0.27.0, the codebase failed to classify NVIDIA DeepStream as a GPU backend. Because of this misclassification, the decode path skipped pixel-limit enforcement checks that would otherwise reject oversized or resource-intensive video payloads.

An attacker submitting a request with a video input can trigger runtime activation of DeepStream. This activation initializes a process-wide GPU decode pool that is shared across concurrent requests. Once initialized, the pool becomes a shared resource bottleneck. Subsequent decode operations bypass the pixel-limit guardrails, allowing large or crafted videos to consume disproportionate GPU decode capacity and degrade throughput for other requests.

EPSS data places exploitation probability at 0.327% as of 2026-08-27.

Root Cause

The root cause is a two-part logic flaw. First, the backend classifier does not identify DeepStream as a GPU backend, so backend-specific safeguards are not applied. Second, the video decode path omits pixel-limit enforcement entirely when routed through DeepStream. Together these gaps allow untrusted input to control initialization of a shared decode pool and to submit payloads that exceed intended resource ceilings.

Attack Vector

Exploitation requires only network access to a vulnerable vLLM inference endpoint. No authentication or user interaction is required. The attacker crafts an inference request that references or embeds video content and forces the DeepStream code path. Once the shared decode pool is initialized, additional requests continue to bypass pixel-limit checks, sustaining the availability impact on concurrent workloads.

             "mistral_common[audio]",
         ],  # Required for audio processing
         "video": [],  # Kept for backwards compatibility
+        # NVIDIA DeepStream (NVDEC) GPU video-decode backend. Linux x86-64
+        # only; also needs system GStreamer + libv4l (see docs).
+        "deepstream": ["nvidia-deepstream-videodecode-cu13>=9.0.2"],
         "flashinfer": [],  # Kept for backwards compatibility
         # Optional deps for Helion kernel development
         # NOTE: When updating helion version, also update CI files:

Source: vLLM security patch commit e23b193. The patch formalizes DeepStream as a distinct optional GPU backend so it can be correctly classified and gated by resource enforcement logic.

Detection Methods for CVE-2026-78684

Indicators of Compromise

• Anomalous spikes in GPU decode utilization on hosts running vLLM inference workers
• Increased latency or timeouts for concurrent inference requests handled by the same vLLM process
• Inbound requests containing video payloads targeting endpoints on hosts that have not opted into DeepStream provisioning
• Log entries showing first-time DeepStream backend initialization triggered by external request traffic

Detection Strategies

• Monitor vLLM process telemetry for the initialization of the DeepStream (NVDEC) decode pool tied to inbound requests rather than startup configuration
• Correlate GPU decoder saturation with request volume from individual clients or IP ranges to identify resource exhaustion patterns
• Alert on video inputs that exceed expected pixel dimensions or bitrate profiles before they reach the decode path

Monitoring Recommendations

• Collect NVIDIA driver and NVDEC metrics alongside vLLM request logs into a centralized data lake for correlation
• Track per-tenant request latency distributions to detect degraded service consistent with DoS conditions
• Enable structured logging for backend selection decisions inside vLLM so DeepStream activations are auditable

How to Mitigate CVE-2026-78684

Immediate Actions Required

• Upgrade vLLM to version 0.27.0 or later on all inference hosts
• Inventory deployments that expose multimodal endpoints and confirm whether DeepStream is intentionally provisioned
• Restrict network access to vLLM inference APIs so only authenticated internal clients can submit requests
• Enforce input validation at an API gateway or reverse proxy to cap video pixel counts and payload sizes

Patch Information

The fix is included in vLLM 0.27.0. Review the vLLM GitHub Security Advisory GHSA-cqm8-jxg6-fqfq and the VulnCheck Denial of Service Advisory for advisory details. The upstream commit e23b193 classifies DeepStream as an explicit optional GPU backend, allowing pixel-limit enforcement to apply in the decode path.

Workarounds

• Disable multimodal video input handling on vLLM deployments that do not require it
• Do not install the nvidia-deepstream-videodecode-cu13 dependency on hosts where DeepStream is not needed
• Place a request-inspecting proxy in front of vLLM to reject oversized video payloads before they reach the decode pool

# Upgrade vLLM to a patched release
pip install --upgrade "vllm>=0.27.0"

# Verify installed version
python -c "import vllm; print(vllm.__version__)"

# Optional: avoid installing the DeepStream extra unless required
# pip install "vllm[deepstream]>=0.27.0"   # only if DeepStream is needed