CVE-2026-34755
published 2026-04-06CVE-2026-34755: vLLM is an inference and serving engine for large language models (LLMs). From 0.7.0 to before 0.19.0, the VideoMediaIO.load_base64() method at…
PriorityP337medium6.5CVSS 3.1
AVNACLPRLUINSUCNINAH
EPSS
0.35%
26.9th percentile
vLLM is an inference and serving engine for large language models (LLMs). From 0.7.0 to before 0.19.0, the VideoMediaIO.load_base64() method at vllm/multimodal/media/video.py splits video/jpeg data URLs by comma to extract individual JPEG frames, but does not enforce a frame count limit. The num_frames parameter (default: 32), which is enforced by the load_bytes() code path, is completely bypassed in the video/jpeg base64 path. An attacker can send a single API request containing thousands of comma-separated base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM. This vulnerability is fixed in 0.19.0.
Affected
3 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| vllm-project | vllm | — | — |
| vllm | vllm | >= 0.7.0 < 0.19.0 | 0.19.0 |
| vllm | vllm | >= 0.7.0 < 0.19.0 | 0.19.0 |
CVSS provenance
nvdv3.16.5MEDIUMCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vendor_redhat6.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
vLLM: vLLM: Denial of Service due to excessive video frame processing
vendor_redhat·2026-04-06·CVSS 6.5
CVE-2026-34755 [MEDIUM] CWE-770 vLLM: vLLM: Denial of Service due to excessive video frame processing
vLLM: vLLM: Denial of Service due to excessive video frame processing
vLLM is an inference and serving engine for large language models (LLMs). From 0.7.0 to before 0.19.0, the VideoMediaIO.load_base64() method at vllm/multimodal/media/video.py splits video/jpeg data URLs by comma to extract individual JPEG frames, but does not enforce a frame count limit. The num_frames parameter (default: 32), which is enforced by the load_bytes() code path, is completely bypassed in the video/jpeg base64 path. An attacker can send a single API request containing thousands of comma-separated base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM. This vulnerability is fixed in 0.19.0.
A flaw was found in vLLM, an inference and serving engine for large languag
OSV
vLLM: Denial of Service via Unbounded Frame Count in video/jpeg Base64 Processing
osv·2026-04-03
CVE-2026-34755 [MEDIUM] vLLM: Denial of Service via Unbounded Frame Count in video/jpeg Base64 Processing
vLLM: Denial of Service via Unbounded Frame Count in video/jpeg Base64 Processing
## Summary
The `VideoMediaIO.load_base64()` method at `vllm/multimodal/media/video.py:51-62` splits `video/jpeg` data URLs by comma to extract individual JPEG frames, but does not enforce a frame count limit. The `num_frames` parameter (default: 32), which is enforced by the `load_bytes()` code path at line 47-48, is completely bypassed in the `video/jpeg` base64 path. An attacker can send a single API request containing thousands of comma-separated base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM.
## Details
### Vulnerable code
```python
# video.py:51-62
def load_base64(self, media_type: str, data: str) -> tuple[npt.NDArray, dict[str, Any]]:
if media_typ
GHSA
vLLM: Denial of Service via Unbounded Frame Count in video/jpeg Base64 Processing
ghsa·2026-04-03
CVE-2026-34755 [MEDIUM] CWE-770 vLLM: Denial of Service via Unbounded Frame Count in video/jpeg Base64 Processing
vLLM: Denial of Service via Unbounded Frame Count in video/jpeg Base64 Processing
## Summary
The `VideoMediaIO.load_base64()` method at `vllm/multimodal/media/video.py:51-62` splits `video/jpeg` data URLs by comma to extract individual JPEG frames, but does not enforce a frame count limit. The `num_frames` parameter (default: 32), which is enforced by the `load_bytes()` code path at line 47-48, is completely bypassed in the `video/jpeg` base64 path. An attacker can send a single API request containing thousands of comma-separated base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM.
## Details
### Vulnerable code
```python
# video.py:51-62
def load_base64(self, media_type: str, data: str) -> tuple[npt.NDArray, dict[str, Any]]:
if media_typ
No detection rules found.
No public exploits indexed.
Wiz
CVE-2026-34755 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz·CVSS 7.1
CVE-2026-34755 [HIGH] CVE-2026-34755 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2026-34755 :
vLLM vulnerability analysis and mitigation
vLLM is an inference and serving engine for large language models (LLMs). From 0.7.0 to before 0.19.0, the VideoMediaIO.load_base64() method at vllm/multimodal/media/video.py splits video/jpeg data URLs by comma to extract individual JPEG frames, but does not enforce a frame count limit. The num_frames parameter (default: 32), which is enforced by the load_bytes() code path, is completely bypassed in the video/jpeg base64 path. An attacker can send a single API request containing thousands of comma-separated base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM. This vulnerability is fixed in 0.19.0.
Source : NVD
## 6.5
Score
Published April 6, 2026
Severity MEDIUM
CNA Scor
Wiz
CVE-2026-25960 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz·CVSS 7.1
CVE-2026-25960 [HIGH] CVE-2026-25960 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2026-25960 :
vLLM vulnerability analysis and mitigation
vLLM is an inference and serving engine for large language models (LLMs). The SSRF protection fix for CVE-2026-24779 add in 0.15.1 can be bypassed in the load_from_url_async method due to inconsistent URL parsing behavior between the validation layer and the actual HTTP client. The SSRF fix uses urllib3.util.parse_url() to validate and extract the hostname from user-provided URLs. However, load_from_url_async uses aiohttp for making the actual HTTP requests, and aiohttp internally uses the yarl library for URL parsing. This vulnerability in 0.17.0.
Source : NVD
## 9.8
Score
Published March 9, 2026
Severity CRITICAL
CNA Score 7.1
Affected Technologies
vLLM
Has Public Exploit Yes
Has CISA KEV Exploit No
CISA KEV Re
Wiz
GHSA-mcmc-2m55-j8jj Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz·CVSS 8.8
CVE-2025-62164 [HIGH] GHSA-mcmc-2m55-j8jj Impact, Exploitability, and Mitigation Steps | Wiz
## GHSA-mcmc-2m55-j8jj :
vLLM vulnerability analysis and mitigation
## Summary
The fix here for CVE-2025-62164 is not sufficient. The fix only disables prompt embeds by default rather than addressing the root cause, so the DoS vulnerability remains when the feature is enabled.
## Details
vLLM's pending change attempts to fix the root cause, which is the missing sparse tensor validation. PyTorch (~v2.0) disables sparse tensor validation (specifically, sparse tensor invariants checks) by default for performance reasons. vLLM is adding the sparse tensor validation to ensure indices are valid, non-negative, and within bounds. These checks help catch malformed tensors.
## PoC
NA
## Impact
Current fix only added a flag to disable/enable prompt embeds, so by default, prompt embeds
Wiz
CVE-2026-34753 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz·CVSS 7.1
CVE-2026-34753 [HIGH] CVE-2026-34753 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2026-34753 :
vLLM vulnerability analysis and mitigation
vLLM is an inference and serving engine for large language models (LLMs). From 0.16.0 to before 0.19.0, a server-side request forgery (SSRF) vulnerability in download_bytes_from_url allows any actor who can control batch input JSON to make the vLLM batch runner issue arbitrary HTTP/HTTPS requests from the server, without any URL validation or domain restrictions.
This can be used to target internal services (e.g. cloud metadata endpoints or internal HTTP APIs) reachable from the vLLM host. This vulnerability is fixed in 0.19.0.
Source : NVD
## 5.4
Score
Published April 6, 2026
Severity MEDIUM
CNA Score 5.4
Affected Technologies
vLLM
Has Public Exploit No
Has CISA KEV Exploit No
CISA KEV Release Date N/A
CISA KEV
Wiz
CVE-2026-34756 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz·CVSS 7.1
CVE-2026-34756 [HIGH] CVE-2026-34756 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2026-34756 :
vLLM vulnerability analysis and mitigation
vLLM is an inference and serving engine for large language models (LLMs). From 0.1.0 to before 0.19.0, a Denial of Service vulnerability exists in the vLLM OpenAI-compatible API server. Due to the lack of an upper bound validation on the n parameter in the ChatCompletionRequest and CompletionRequest Pydantic models, an unauthenticated attacker can send a single HTTP request with an astronomically large n value. This completely blocks the Python asyncio event loop and causes immediate Out-Of-Memory crashes by allocating millions of request object copies in the heap before the request even reaches the scheduling queue. This vulnerability is fixed in 0.19.0.
Source : NVD
## 6.5
Score
Published April 6, 2026
Severity MEDIU
Bugzilla
CVE-2026-34755 vLLM: vLLM: Denial of Service due to excessive video frame processing
bugzilla·2026-04-06·CVSS 6.5
CVE-2026-34755 [MEDIUM] CVE-2026-34755 vLLM: vLLM: Denial of Service due to excessive video frame processing
CVE-2026-34755 vLLM: vLLM: Denial of Service due to excessive video frame processing
vLLM is an inference and serving engine for large language models (LLMs). From 0.7.0 to before 0.19.0, the VideoMediaIO.load_base64() method at vllm/multimodal/media/video.py splits video/jpeg data URLs by comma to extract individual JPEG frames, but does not enforce a frame count limit. The num_frames parameter (default: 32), which is enforced by the load_bytes() code path, is completely bypassed in the video/jpeg base64 path. An attacker can send a single API request containing thousands of comma-separated base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM. This vulnerability is fixed in 0.19.0.
2026-04-06
Published