CVE-2026-34755: 
NixOS vulnerability analysis and mitigation

CVE-2026-34755 is a Denial of Service vulnerability in vLLM (an inference and serving engine for large language models) caused by an unbounded frame count in the VideoMediaIO.load_base64() method when processing video/jpeg base64-encoded data URLs. It affects vLLM versions 0.7.0 through 0.18.x (fixed in 0.19.0). The vulnerability was reported by researcher SEORY0, published to the GitHub Advisory Database on April 3, 2026, and assigned CVE ID on April 6, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (Github Advisory, Red Hat Bugzilla).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling). In vllm/multimodal/media/video.py (lines 51–62), the load_base64() method handles video/jpeg media type by splitting the data string on commas (data.split(",")) to extract individual JPEG frames, but applies no limit on the number of frames processed. The num_frames parameter (default: 32) is enforced only in the load_bytes() code path (lines 47–48); the video/jpeg base64 path bypasses it entirely. An authenticated attacker with low privileges can send a single POST /v1/chat/completions API request containing thousands of comma-separated base64-encoded JPEG frames — the data flows through chat_utils.py → connector.py → video.py:54 where data.split(",") produces an unbounded list, each frame is decoded into a numpy array, and np.stack() creates an additional combined copy, resulting in massive memory consumption (Github Advisory, vLLM Security Advisory).

Successful exploitation causes server-side out-of-memory (OOM) crashes, resulting in complete loss of availability for the vLLM inference service. The memory amplification is significant: for 640×480 RGB JPEG frames, each frame decompresses to approximately 921 KB as a numpy array, meaning 5,000 frames (~100 KB compressed) expand to ~4.6 GB in memory, with np.stack() creating an additional copy. There is no confidentiality or integrity impact — the vulnerability is purely a denial-of-service condition affecting the availability of LLM inference endpoints (Github Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The vulnerability requires low privileges (authenticated API access) but no user interaction, and has low attack complexity. The EPSS score is approximately 0.054% (17th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory).

1. Identify target: Locate a vLLM instance (versions 0.7.0–0.18.x) exposing the /v1/chat/completions API endpoint, accessible with valid API credentials.
2. Craft malicious payload: Generate thousands of small base64-encoded JPEG images (e.g., 5,000 frames of 640×480 RGB images, totaling ~100 KB compressed). Encode each frame individually in base64 and join them with commas.
3. Construct the data URL: Format the payload as a video/jpeg data URL: data:video/jpeg;base64,<frame1_b64>,<frame2_b64>,...,<frameN_b64>.
4. Send the API request: Submit a POST /v1/chat/completions request with the crafted video_url in the message content, using a multimodal-capable model. The request routes through chat_utils.py → connector.py → VideoMediaIO.load_base64().
5. Trigger OOM: The server splits the data on all commas (unbounded), decodes every frame into a numpy array, and calls np.stack(), exhausting server memory and causing an OOM crash that takes down the vLLM service (vLLM Security Advisory).

• Network: Unusually large POST /v1/chat/completions requests (potentially hundreds of KB to MB in size) containing data:video/jpeg;base64, data URLs with many comma-separated segments.
• Logs: vLLM server logs showing Python MemoryError or OOM kill signals (e.g., Linux kernel OOM killer messages in system logs) shortly after processing a multimodal API request; access logs showing large request body sizes from a single source IP.
• Process: Sudden spike in memory consumption by the vLLM Python process followed by process termination; dmesg or /var/log/syslog entries containing Out of memory: Kill process referencing the vLLM worker.
• File System: Core dump files generated by the vLLM process if core dumps are enabled (vLLM Security Advisory).

Upgrade vLLM to version 0.19.0 or later, which enforces the num_frames limit in the load_base64() method for video/jpeg data URLs via PR #38636 (commit 58ee614). The fix truncates frames exceeding self.num_frames using data.split(",", self.num_frames)[:self.num_frames] and handles edge cases for num_frames=-1 (no limit) and num_frames=0 (raises ValueError). As a short-term workaround where upgrading is not immediately possible, restrict API access to trusted authenticated users only and consider placing rate limits or request body size limits at the API gateway or reverse proxy layer (Github Advisory, Fix PR).

Red Hat tracked the vulnerability via their security response process (Bugzilla bug 2455403) with a high severity/priority rating, indicating concern for downstream users of vLLM in Red Hat products. The fix was coordinated by vLLM maintainer russellb and implemented by contributor jperezdealgaba with review from core maintainers DarkLight1337 and Isotr0py. No significant broader media coverage or notable social media discussion has been identified beyond the standard advisory channels (Red Hat Bugzilla, Fix PR).