CVE-2026-34755
Memory Exhaustion via Unrestricted Frame Parsing in vLLM VideoMediaIO
Publication date: 2026-04-06
Last updated on: 2026-04-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| vllm | vllm | From 0.7.0 (inc) to 0.19.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the vLLM project's method VideoMediaIO.load_base64() which processes video/jpeg Base64-encoded data URLs by splitting the input string on commas to extract individual JPEG frames.
Unlike another method load_bytes() that enforces a limit on the number of frames processed (default 32), load_base64() does not impose any frame count limit.
An attacker can exploit this by sending a single API request containing thousands of comma-separated Base64-encoded JPEG frames. Each frame is decoded into memory, and the method combines all frames into a single numpy array, which duplicates memory usage.
This causes the server to consume excessive memory (for example, 5,000 frames can use about 4.6 GB RAM), leading to an Out-Of-Memory (OOM) crash and denial of service.
The vulnerability is fixed in version 0.19.0 by adding a frame count limit in the load_base64() method.
How can this vulnerability impact me? :
This vulnerability can cause a Denial of Service (DoS) condition by crashing the server due to memory exhaustion.
An attacker can send a specially crafted API request with thousands of Base64-encoded JPEG frames, causing the server to decode all frames into memory and run out of available RAM.
This results in the server becoming unavailable or crashing, impacting the availability of the service.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusually large or suspicious POST requests to the /v1/chat/completions endpoint that contain video/jpeg Base64-encoded data URLs with an excessive number of comma-separated frames.
One approach is to inspect incoming API requests for the presence of video/jpeg data URLs and count the number of frames (comma-separated Base64-encoded JPEG images) included in the payload.
Example commands to detect such requests might include using network traffic inspection tools or logs filtering, for instance:
- Using grep or similar tools on server logs to find requests containing 'video/jpeg' and counting commas in the data field to estimate frame count.
- Example shell command to count frames in a logged request payload: `echo "<base64_data>" | grep -o ',' | wc -l`
- Using packet capture tools like tcpdump or Wireshark to filter POST requests to /v1/chat/completions and analyze payload sizes and content.
Additionally, monitoring server memory usage for spikes during processing of such requests can help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the vLLM software to version 0.19.0 or later, where the vulnerability is fixed by enforcing a frame count limit in the load_base64() method.
If upgrading is not immediately possible, consider implementing request filtering or rate limiting on the /v1/chat/completions endpoint to block or throttle requests containing large numbers of comma-separated Base64-encoded JPEG frames.
Monitoring and alerting on abnormal memory usage or unusually large payloads can also help mitigate the impact until a patch is applied.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability causes a Denial of Service (DoS) by exhausting server memory, leading to availability impact. However, it does not affect confidentiality or integrity of data.
Since the vulnerability does not result in unauthorized access, data leakage, or data modification, it does not directly impact compliance with data protection regulations such as GDPR or HIPAA, which primarily focus on confidentiality and integrity of personal or sensitive data.
Nonetheless, the availability impact caused by this vulnerability could indirectly affect compliance if the service outage prevents timely access to data or services required under these regulations.