CVE-2026-69147: vLLM — MEDIUM

Q: Is CVE-2026-69147 actively exploited?

No confirmed active exploitation of CVE-2026-69147 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-69147?

Update to patched version: vLLM 0.28.0.

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.46%.

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...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	< 0.28.0	`0.28.0`
91.6K 92 dependents Pushed 6d ago 27% patched ~49d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 39% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

N/A

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I None

A High

What should I do?

Patch available

Update vLLM to version 0.28.0

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-69147?

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.

Is CVE-2026-69147 actively exploited?

No confirmed active exploitation of CVE-2026-69147 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-69147?

Update to patched version: vLLM 0.28.0.

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.46%.

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.

Weaknesses (CWE)

CWE-400 Uncontrolled Resource Consumption Primary CWE-770 Allocation of Resources Without Limits or Throttling Primary CWE-400 Uncontrolled Resource Consumption CWE-400 Uncontrolled Resource Consumption CWE-770 Allocation of Resources Without Limits or Throttling CWE-770 Allocation 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.