CVE-2026-69147: vLLM: request-selected video backend exhausts GPU memory

Q: Is CVE-2026-69147 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-69147, increasing the risk of exploitation.

Q: How to fix CVE-2026-69147?

1) Upgrade vllm to 0.28.0 or later (see the advisory GHSA-8pw2-6jv3-mj5j and PR 47259). 2) If you cannot patch yet, uninstall PyNvVideoCodec from serving images so the backend cannot be selected. 3) Have the API gateway or reverse proxy strip or reject the media_io_kwargs.video.video_backend field in request bodies, or disable video input if it is not needed. 4) Enforce per-user rate limits, request size limits and concurrency caps on multimodal endpoints. 5) Require authentication on all vLLM endpoints and do not expose them directly to the internet. 6) Monitor GPU memory use outside the KV-cache budget, CUDA OOM errors, worker restarts, and requests that set video_backend to a non-default value.

Q: What systems are affected by CVE-2026-69147?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, multimodal inference, multi-tenant GPU clusters, OpenAI-compatible API endpoints.

Q: What is the CVSS score for CVE-2026-69147?

CVE-2026-69147 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.58%.

GHSA-8pw2-6jv3-mj5jMEDIUMPoC AVAILABLECISA: TRACK*

Published September 16, 2026

CISO Take

CVE-2026-69147 lets an authenticated API user choose the pynvvideocodec video backend in a Chat Completions or Responses request, bypassing the software decoder configured at startup. The engine does not count that decoder's CUDA context and frame allocations in its KV-cache budget, so a stream of video requests can exhaust shared GPU memory and cause request failures, worker crashes, or denial of service. Severity is medium (CVSS 6.5, availability impact only), with no public exploit, no Nuclei template, no CISA KEV listing, an EPSS of 0.58% (top 54%) and an SSVC decision of TRACK*. The affected package has 95 downstream dependents and 145 other CVEs, so it is widely used and frequently patched. Only deployments that serve video input on GPUs with PyNvVideoCodec installed are exposed. Upgrade vLLM to 0.28.0 or later, and until then remove PyNvVideoCodec from inference images or block video inputs at the gateway.

Sources:NVDGitHub AdvisoryEPSSATLASCISA SSVC

What is the risk?

Medium overall. Exploitation is easy (network, low complexity, low privileges, no user interaction) but the impact is limited to availability. The preconditions narrow exposure: a video-capable GPU deployment, PyNvVideoCodec installed, and an attacker with at least low-privilege API access. There is no known public exploit or in-the-wild activity (not in KEV, EPSS 0.58%). The risk rises for multi-tenant or internet-exposed inference endpoints, where one user can degrade service for all others sharing the GPU.

How does the attack unfold?

Initial Access

The attacker authenticates to a video-capable vLLM OpenAI-compatible endpoint with a low-privilege API key.

AML.T0040

Backend Override

The attacker sets media_io_kwargs.video.video_backend to pynvvideocodec in request bodies, overriding the startup software decoder.

AML.T0049

Resource Exhaustion

Concurrent video requests create CUDA contexts and decoder frame allocations that the engine's KV-cache budget does not account for.

AML.T0034.001

Impact

GPU memory runs out, causing request failures, worker crashes and denial of service for all users of the node.

AML.T0029

Initial Access

The attacker authenticates to a video-capable vLLM OpenAI-compatible endpoint with a low-privilege API key.

AML.T0040

Backend Override

The attacker sets media_io_kwargs.video.video_backend to pynvvideocodec in request bodies, overriding the startup software decoder.

AML.T0049

Resource Exhaustion

Concurrent video requests create CUDA contexts and decoder frame allocations that the engine's KV-cache budget does not account for.

AML.T0034.001

Impact

GPU memory runs out, causing request failures, worker crashes and denial of service for all users of the node.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	< 0.28.0	`0.28.0`
96.0K94 dependentsPushed 5d ago27% patched~37d to patchFull package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.6%

chance of exploitation in 30 days

Higher than 48% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vllm to 0.28.0 or later (see the advisory GHSA-8pw2-6jv3-mj5j and PR 47259). 2) If you cannot patch yet, uninstall PyNvVideoCodec from serving images so the backend cannot be selected. 3) Have the API gateway or reverse proxy strip or reject the media_io_kwargs.video.video_backend field in request bodies, or disable video input if it is not needed. 4) Enforce per-user rate limits, request size limits and concurrency caps on multimodal endpoints. 5) Require authentication on all vLLM endpoints and do not expose them directly to the internet. 6) Monitor GPU memory use outside the KV-cache budget, CUDA OOM errors, worker restarts, and requests that set video_backend to a non-default value.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoSInferenceAPIFrameworkAML.T0029- Denial of AI Service AML.T0034.001- Resource-Intensive Queries AML.T0040- AI Model Inference API Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Response to unknown or unexpected risks and system failure

OWASP LLM Top 10

LLM10:2025-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-69147?

Is CVE-2026-69147 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-69147, increasing the risk of exploitation.

How to fix CVE-2026-69147?

1) Upgrade vllm to 0.28.0 or later (see the advisory GHSA-8pw2-6jv3-mj5j and PR 47259). 2) If you cannot patch yet, uninstall PyNvVideoCodec from serving images so the backend cannot be selected. 3) Have the API gateway or reverse proxy strip or reject the media_io_kwargs.video.video_backend field in request bodies, or disable video input if it is not needed. 4) Enforce per-user rate limits, request size limits and concurrency caps on multimodal endpoints. 5) Require authentication on all vLLM endpoints and do not expose them directly to the internet. 6) Monitor GPU memory use outside the KV-cache budget, CUDA OOM errors, worker restarts, and requests that set video_backend to a non-default value.

What systems are affected by CVE-2026-69147?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, multimodal inference, multi-tenant GPU clusters, OpenAI-compatible API endpoints.

What is the CVSS score for CVE-2026-69147?

CVE-2026-69147 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.58%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inferencemultimodal inferencemulti-tenant GPU clustersOpenAI-compatible API endpoints

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0034.001Resource-Intensive Queries

AML.T0040AI Model Inference API Access

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker with a low-privilege API key for a company's internal or hosted vLLM service finds that video input is enabled and sends Chat Completions requests containing video URLs. Each request sets media_io_kwargs.video.video_backend to pynvvideocodec. The server creates a CUDA context and decoder surfaces for every request and holds decoded frames outside the engine's memory accounting. Sending many concurrent requests exhausts GPU memory, so legitimate inference requests fail with out-of-memory errors and workers crash or restart repeatedly until the attacker stops.

Weaknesses (CWE)

CWE-400Uncontrolled Resource ConsumptionPrimary CWE-770Allocation of Resources Without Limits or ThrottlingPrimary CWE-400Uncontrolled Resource Consumption CWE-400Uncontrolled Resource Consumption CWE-770Allocation of Resources Without Limits or Throttling CWE-770Allocation of Resources Without Limits or Throttling

CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.

[Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
[Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Source: MITRE CWE corpus.