EUVD-2026-80935
GHSA-8pw2-6jv3-mj5j
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain API access to video-capable vLLM endpoint
-
DeliveryCraft request with media_io_kwargs.video.video_backend=pynvvideocodec
-
ExploitForce unbudgeted GPU decoder allocation
-
ExecutionRepeat to exhaust shared GPU memory
-
ImpactWorker crash / denial of service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a specific, non-default multimodal stack: (1) a vLLM deployment before 0.28.0 that is video-capable and serving a model accepting video input via Chat Completions or Responses; (2) the PyNvVideoCodec library actually installed on the GPU host; and (3) startup configuration having selected a software video decoder (the bug is that the request-level 'pynvvideocodec' backend overrides this without being memory-budgeted). The attacker must be able to submit video requests, matching PR:L - some level of API access is needed, but vLLM ships without built-in authentication, so this is a low bar in many deployments. Limiting factors: text-only or non-video vLLM deployments, hosts without PyNvVideoCodec installed, and any version 0.28.0 or later are not exploitable; impact is confined to availability (GPU memory exhaustion / worker crash), with no data exposure or code execution. |
| Impact | This is a genuine but bounded availability-only issue, not a high-priority critical flaw. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, 6.5 Medium) is internally consistent with the description: a network-reachable, low-complexity, authenticated request that impacts only availability (CWE-400 resource exhaustion) with no confidentiality or integrity impact. No EPSS score was provided in the input, there is no CISA KEV listing, and no public exploit code is referenced - the linked GitHub artifacts are the security advisory, the fix PR (#47259), and two remediation commits, not weaponized POCs. PR:L is well-justified because the attacker must be able to submit inference requests to the deployment; vLLM ships with no built-in authentication, so 'low privilege' realistically means any client with API access, which in many self-hosted deployments is a broad set. The practical risk is further gated by a specific non-default stack (see exploitation conditions), so this is a targeted operational-availability concern for a subset of multimodal GPU deployments rather than a widespread emergency. No signals conflict; the main gap is the absent EPSS value, which prevents a probabilistic exploitation estimate. |
| Exploit ScenarioDerived | An attacker with API access to a video-capable vLLM GPU endpoint (running before 0.28.0 with PyNvVideoCodec installed) submits Chat Completions or Responses requests that set media_io_kwargs.video.video_backend to 'pynvvideocodec', forcing the GPU decoder even though startup config selected a software decoder. Because _reserve_mm_ipc_gpu_memory only budgets from static config, the request-selected backend allocates an unbudgeted CUDA context, decoder surfaces, and decoded-frame buffers that eat into the KV-cache budget, and repeated requests exhaust shared GPU memory. This results in request failures, worker crashes, and denial of service; no public exploit code is identified at time of analysis, though the trivial request-body manipulation makes it easy to reproduce. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 16, 2026
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS vector) force the server to load the PyNvVideoCodec hardware video decoder on demand by setting media_io_kwargs.video.video_backend to 'pynvvideocodec' in a Chat Completions or Responses request, even when the operator configured a software decoder at startup. Because the engine budgets decoder VRAM only from static configuration, the request-selected backend allocates a CUDA context, decoder surfaces, and decoded-frame buffers that were never deducted from the KV-cache budget, so repeated video requests can exhaust shared GPU memory and cause request failures, worker crashes, and denial of service. The issue is availability-only (C:N/I:N/A:H) and exploitable only on video-capable GPU deployments running a video-accepting model with PyNvVideoCodec actually installed; vLLM 0.28.0 and later are not affected. No public exploit code was identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV), though the upstream fix commits and PR are publicly visible.
RemediationAI
Vendor-released patch: upgrade vLLM to 0.28.0 or later, which contains the merge_kwargs policy change that strips request-level 'video_backend'/'backend' values requiring the GPU unless they match the startup configuration - apply it via the vendor advisory at https://github.com/vllm-project/vllm/security/advisories/GHSA-8pw2-6jv3-mj5j or by picking up pull request https://github.com/vllm-project/vllm/pull/47259 (commits 283893c72292ede38d277e3cd2b9b64c3e4f1dda and ba22152096b2484faa3579624a253d54804d876d). If immediate upgrade is not possible, the most effective compensating control is to remove the attack surface entirely by uninstalling or excluding PyNvVideoCodec from the GPU host, so that the pynvvideocodec backend cannot be instantiated; the trade-off is loss of hardware-accelerated video decoding, which may reduce video-ingest throughput. Where the codec must remain installed, restrict who can submit video-bearing requests to the Chat Completions and Responses endpoints (vLLM ships without built-in authentication, so an authenticating reverse proxy or network-level allowlisting in front of the API is required) and cap per-client request concurrency to limit how many decoding contexts can be created in parallel - both add operational overhead and can degrade legitimate multimodal workloads. Operators should also monitor GPU memory headroom and worker restarts for signs of budget overrun, and be aware that because the engine only budgets VRAM from static configuration, enforcing a consistent static decoder choice does not by itself prevent the per-request backend override on unpatched builds.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-400, Uncontrolled Resource Consumption, in vLLM's multimodal media pipeline. vLLM resolves video decoding backends through VIDEO_LOADER_REGISTRY, an ExtensionManager-backed registry of loaders (software backends such as opencv, pyav, and torchcodec, plus the GPU-backed PyNvVideoCodec registered under PYNVVIDEOCODEC_VIDEO_BACKEND). VideoMediaIO.merge_kwargs previously merged request-supplied runtime kwargs such as 'video_backend' and the codec-level 'backend' key over the engine's static defaults without any policy check, and MediaConnector.fetch_video forwarded the resulting choice to VideoMediaIO. The engine's _reserve_mm_ipc_gpu_memory budgeting logic sizes decoder memory reservations exclusively from the startup configuration, so when a request flipped the backend to the PyNvVideoCodec hardware decoder, the newly created CUDA context, decoder surfaces, and decoded-frame allocations consumed GPU memory outside the accounted KV-cache budget. The upstream fix adds a requires_gpu flag to VIDEO_LOADER_REGISTRY.register (PyNvVideoCodec registered with requires_gpu=True) and a backend_requires_gpu() lookup, then makes merge_kwargs strip any request-level 'video_backend' or 'backend' value that requires the GPU unless the identical value was already present in the static (startup) configuration, emitting a warning_once when it does so. The accompanying tests exercise exactly this strip/preserve behavior, confirming that software backends pass through unchanged while unconfigured GPU backends are removed from the merged kwargs.
Know when Vllm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Network-reachable request with no built-in auth maps to PR:L and AC:L; impact is pure GPU-memory exhaustion (A:H) with no confidentiality or integrity effect, and no scope change.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
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.
Blast Radius
ecosystem impact- 2 pypi packages depend on vllm (2 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.28.0.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the sh
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Memory exhaustion in vLLM 0.22.0-0.23.0 allows authenticated API callers to crash or destabilize the inference server by
Exploit-DB