AI Threat AlertCVE-2026-126399: vLLM: num_frames bypass causes memory exhaustion DoS
MEDIUMvLLM versions 0.19.0 up to (but not including) 0.31.0 let any authenticated inference client override the server's video frame limit through the media_io_kwargs.video.num_frames field in chat completion requests. By sending num_frames=-1 or a very large value with many base64 JPEG frames, an attacker forces the server to decode every frame and stack them in memory, which can exhaust RAM and crash or stall the inference service. The CVSS score is a moderate 6.5, with network reachability, low complexity and only low privileges required, but the impact is availability-only; there is no confidentiality or integrity loss. No EPSS score, public exploit, Nuclei template or CISA KEV listing exists at this time, so near-term mass exploitation looks unlikely, yet the trigger is a single well-formed API request and is trivial to reproduce once the advisory is read. Upgrade to vLLM 0.31.0 or later, and until then enforce request size limits and restrict who can call multimodal chat endpoints, especially on shared or multi-tenant GPU serving.
What is the risk?
Medium risk. Exploitation is network-based, low complexity and needs only low privileges (a valid API client), with no user interaction. Impact is limited to availability (CVSS A:H), but a single request can take down a shared inference node and every tenant on it. No public exploit, Nuclei template, KEV listing or EPSS data is available, so exploitation likelihood is currently low-to-moderate. Exposure is highest for internet-facing or multi-tenant vLLM deployments that accept video input and have weak rate limiting.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade vLLM to 0.31.0 or later. 2) Until patched, block or strip the media_io_kwargs field (particularly video.num_frames) at an API gateway or reverse proxy, and reject requests with negative or unusually large values. 3) Enforce maximum request body size, maximum number of media items per request, and per-client rate limits. 4) Set container and pod memory limits with automatic restart, and isolate multimodal serving from other workloads. 5) Require authentication on all inference endpoints and avoid exposing them directly to the internet. 6) Monitor for abnormal memory growth, OOM kills, unusually large chat completion payloads and requests containing media_io_kwargs. 7) Review the GitHub advisory GHSA-vxqj-p4gw-9h4c for the exact fix details.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-126399?
vLLM versions 0.19.0 up to (but not including) 0.31.0 let any authenticated inference client override the server's video frame limit through the media_io_kwargs.video.num_frames field in chat completion requests. By sending num_frames=-1 or a very large value with many base64 JPEG frames, an attacker forces the server to decode every frame and stack them in memory, which can exhaust RAM and crash or stall the inference service. The CVSS score is a moderate 6.5, with network reachability, low complexity and only low privileges required, but the impact is availability-only; there is no confidentiality or integrity loss. No EPSS score, public exploit, Nuclei template or CISA KEV listing exists at this time, so near-term mass exploitation looks unlikely, yet the trigger is a single well-formed API request and is trivial to reproduce once the advisory is read. Upgrade to vLLM 0.31.0 or later, and until then enforce request size limits and restrict who can call multimodal chat endpoints, especially on shared or multi-tenant GPU serving.
Is CVE-2026-126399 actively exploited?
No confirmed active exploitation of CVE-2026-126399 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-126399?
1) Upgrade vLLM to 0.31.0 or later. 2) Until patched, block or strip the media_io_kwargs field (particularly video.num_frames) at an API gateway or reverse proxy, and reject requests with negative or unusually large values. 3) Enforce maximum request body size, maximum number of media items per request, and per-client rate limits. 4) Set container and pod memory limits with automatic restart, and isolate multimodal serving from other workloads. 5) Require authentication on all inference endpoints and avoid exposing them directly to the internet. 6) Monitor for abnormal memory growth, OOM kills, unusually large chat completion payloads and requests containing media_io_kwargs. 7) Review the GitHub advisory GHSA-vxqj-p4gw-9h4c for the exact fix details.
What systems are affected by CVE-2026-126399?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference servers, multimodal pipelines, multi-tenant inference platforms, OpenAI-compatible API gateways.
What is the CVSS score for CVE-2026-126399?
CVE-2026-126399 has a CVSS v3.1 base score of 6.5 (MEDIUM).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0034.001Resource-Intensive QueriesAML.T0040AI Model Inference API AccessCompliance Controls Affected
What are the technical details?
Original Advisory
vLLM from 0.19.0 before 0.31.0 contains a resource exhaustion vulnerability that allows inference clients to bypass the server frame limit by setting media_io_kwargs.video.num_frames in chat completion requests. Attackers can supply num_frames=-1 or a large value with many base64 JPEG frames, forcing VideoMediaIO to decode all frames and np.stack them, causing memory exhaustion.
Exploitation Scenario
An attacker obtains a low-privilege API key for a company-hosted vLLM service running a vision-language model. They send a chat completion request containing a video input made of thousands of base64-encoded JPEG frames and set media_io_kwargs.video.num_frames to -1, bypassing the server's configured frame cap. The server decodes every frame and attempts to np.stack them into one array, consuming all available memory. The worker is OOM-killed or becomes unresponsive, and repeating the request keeps the service down for all users, disrupting chatbots, agents and pipelines that depend on it.
Weaknesses (CWE)
CWE-770Allocation of Resources Without Limits or ThrottlingPrimaryCWE-770Allocation of Resources Without Limits or ThrottlingCWE-770 — Allocation of Resources Without Limits or Throttling: 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.
- [Requirements] Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
- [Architecture and Design] Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm