Skip to main content

Python CVE-2026-34755

| EUVDEUVD-2026-19350 MEDIUM
Allocation of Resources Without Limits or Throttling (CWE-770)
2026-04-03 https://github.com/vllm-project/vllm GHSA-pq5c-rjhq-qp7p
6.5
CVSS 3.1 · Vendor: https://github.com/vllm-project/vllm
Share

Severity by source

Vendor (https://github.com/vllm-project/vllm) PRIMARY
6.5 MEDIUM
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
6.5 HIGH
qualitative

Primary rating from Vendor (https://github.com/vllm-project/vllm).

CVSS VectorVendor: https://github.com/vllm-project/vllm

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
EUVD ID Assigned
Apr 03, 2026 - 22:15 euvd
EUVD-2026-19350
Analysis Generated
Apr 03, 2026 - 22:15 vuln.today
Patch released
Apr 03, 2026 - 22:15 nvd
Patch available
CVE Published
Apr 03, 2026 - 21:51 nvd
MEDIUM 6.5

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 3 pypi packages depend on vllm (3 direct, 0 indirect)

Ecosystem-wide dependent count for version 0.7.0.

DescriptionCVE.org

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_type.lower() == "video/jpeg":
        load_frame = partial(self.image_io.load_base64, "image/jpeg")
        return np.stack(
            [np.asarray(load_frame(frame_data)) for frame_data in data.split(",")]
#                                                       ^^^^^^^^^^
# Unbounded split - no frame count limit
        ), {}
    return self.load_bytes(base64.b64decode(data))

The load_bytes() path (line 47-48) properly delegates to a video loader that respects self.num_frames (default 32). The load_base64("video/jpeg", ...) path bypasses this limit entirely - data.split(",") produces an unbounded list and every frame is decoded into a numpy array.

video/jpeg is part of vLLM's public API

video/jpeg is a vLLM-specific MIME type, not IANA-registered. However it is part of the public API surface:

  • encode_video_url() at vllm/multimodal/utils.py:96-108 generates data:video/jpeg;base64,... URLs
  • Official test suites at tests/entrypoints/openai/test_video.py:62 and tests/entrypoints/test_chat_utils.py:153 both use this format

Memory amplification

Each JPEG frame decodes to a full numpy array. For 640x480 RGB images, each frame is ~921 KB decoded. 5000 frames = ~4.6 GB. np.stack() then creates an additional copy. The compressed JPEG payload is small (~100 KB for 5000 frames) but decompresses to gigabytes.

Data flow

POST /v1/chat/completions
  → chat_utils.py:1434   video_url type → mm_parser.parse_video()
  → chat_utils.py:872    parse_video() → self._connector.fetch_video()
  → connector.py:295     fetch_video() → load_from_url(url, self.video_io)
  → connector.py:91      _load_data_url(): url_spec.path.split(",", 1)
                          → media_type = "video/jpeg"
                          → data = "<frame1>,<frame2>,...,<frame10000>"
  → connector.py:100     media_io.load_base64("video/jpeg", data)
  → video.py:54          data.split(",")  ← UNBOUNDED
  → video.py:55-57       all frames decoded into numpy arrays
  → video.py:56          np.stack([...])  ← massive combined array → OOM

connector.py:91 uses split(",", 1) which splits on only the first comma. All remaining commas stay in data and are later split by video.py:54.

Comparison with existing protections

Code PathFrame LimitFile
load_bytes() (binary video)Yes - num_frames (default 32)video.py:46-49
load_base64("video/jpeg", ...)No - unlimited data.split(",")video.py:51-62

AnalysisAI

Denial of service in vLLM's VideoMediaIO.load_base64() method allows authenticated remote attackers to crash the server via memory exhaustion by sending API requests with thousands of comma-separated base64-encoded JPEG frames. The vulnerability bypasses the default 32-frame limit enforced in other video loading code paths, allowing attackers to decode gigabytes of image data into memory (e.g., 5000 frames ≈ 4.6 GB for 640x480 RGB) with a small compressed payload. CVSS 6.5 (network-accessible, low complexity, requires authentication, high availability impact); no public exploit code identified at time of analysis.

Technical ContextAI

vLLM is a Python-based LLM inference framework (CPE: pkg:pip/vllm) that provides multimodal input support including video processing via its VideoMediaIO class. The vulnerability stems from improper input validation in the load_base64() method at vllm/multimodal/media/video.py, lines 51-62. When processing video/jpeg MIME type (a vLLM-specific format, not IANA-registered), the code uses Python's str.split(",") to extract individual base64-encoded JPEG frames without enforcing any frame count limit. In contrast, the load_bytes() code path for binary video input properly respects self.num_frames (default 32). The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the unbounded list comprehension [np.asarray(load_frame(frame_data)) for frame_data in data.split(",")] followed by np.stack() creates memory amplification. Each JPEG frame decompresses to ~921 KB for 640x480 RGB, and np.stack() allocates an additional contiguous copy, making small compressed payloads decompress to gigabytes.

RemediationAI

Patch the vulnerability by applying the fix from GitHub commit 58ee61422169ce17e08248f8efa1e9df434fe395 or PR #38636, which enforces the frame count limit in the load_base64() video/jpeg code path matching the behavior of load_bytes(). Update vLLM to the patched version (exact version number not specified in input but available from https://github.com/vllm-project/vllm/pull/38636). As a temporary mitigation before patching, restrict or disable video/jpeg input support via API configuration, implement strict HTTP request size limits (e.g., Content-Length headers), or deploy request size validation upstream of vLLM. Review and test the vendor's patch thoroughly in staging before production deployment. Refer to the GitHub Security Advisory at https://github.com/advisories/GHSA-pq5c-rjhq-qp7p for detailed remediation guidance.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t

CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser

CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi

CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica

CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph

CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.

CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301

CVE-2026-55255 HIGH POC
8.4 Jun 19

Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing

Vendor StatusVendor

Share

CVE-2026-34755 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy