CVE-2026-34755: vLLM Affected by Denial of Service via Unbounded Frame Count in video/jpeg Base64 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.
Security readout for executives and security teams
Plain-English summary
A low-privileged remote user can submit an oversized sequence of JPEG video frames to a vulnerable vLLM service. The service may decode every frame into memory, exhaust available memory, and crash. The issue affects availability; the supplied evidence does not indicate data theft or modification.
Executive priority
Treat this as a prompt availability remediation for exposed or shared AI inference services. Schedule an upgrade quickly where untrusted or low-privileged users can submit multimodal requests. Emergency handling is most justified for business-critical services with limited memory isolation or weak request controls.
Technical view
vLLM versions 0.7.0 through 0.18.x fail to enforce the configured frame limit in VideoMediaIO.load_base64() for video/jpeg data URLs. Comma-separated frames are decoded without a count bound, bypassing the limit applied by load_bytes(). Excessive decoding can cause out-of-memory termination. Version 0.19.0 fixes the flaw.
Likely exposure
Exposure is likely where affected vLLM versions accept network API requests containing video/jpeg base64 input from low-privileged users. Risk is lower when multimodal video input is unavailable or access is tightly restricted. The source bundle does not identify specific deployment configurations or downstream products beyond vLLM.
Exploitation context
CVSS 3.1 rates this 6.5: network-accessible, low complexity, low privileges required, no user interaction, and high availability impact. The supplied record is not in KEV, and no cited source establishes active exploitation. A single malicious request may be sufficient to cause memory exhaustion.
Researcher notes
The defect is CWE-770 resource allocation without limits. The vulnerable base64 path splits video/jpeg data URLs by commas and processes every resulting frame, unlike load_bytes(), which enforces num_frames. Assessment should focus on path reachability, authentication boundaries, memory isolation, and whether service supervisors limit outage duration.
Mitigation direction
Upgrade vLLM to version 0.19.0 or later.
Prioritize internet-facing or multi-tenant services accepting video/jpeg base64 input.
Until upgraded, restrict multimodal API access to trusted users.
Apply request-size controls where operationally appropriate.
Monitor vendor and Red Hat guidance for deployment-specific updates.
Validation and detection
Inventory vLLM installations and identify versions from 0.7.0 through 0.18.x.
Determine whether exposed endpoints accept video/jpeg base64 data URLs.
Confirm upgraded services report vLLM 0.19.0 or later.
Review logs and telemetry for out-of-memory crashes linked to multimodal requests.
Verify request controls and authentication apply to affected endpoints.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-770: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-770 · source CWE mapping
Allocation of Resources Without Limits or Throttling
Allocation of Resources Without Limits or Throttling represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.