vLLM
CVE-2026-105758
MEDIUM
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach unauthenticated /tokenize endpoint
-
ExploitSubmit inflated max_frames/fps in media_io_kwargs with attacker video
-
ExecutionSampler decodes all frames, exhausts frontend memory
-
ImpactAPI process terminates, service denied
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a vLLM instance version 0.24.0 through 0.29.x running the Python frontend (the Rust frontend is explicitly NOT affected because it rejects the media_io_kwargs field) and serving a model that uses Qwen2VLVideoBackend or Qwen3VLVideoBackend - i.e. a Qwen2-VL or Qwen3-VL video-capable multimodal model. The attacker must be able to reach the /tokenize HTTP endpoint and supply request-level media_io_kwargs.video.max_frames and media_io_kwargs.video.fps values together with attacker-controlled video input. No authentication or user interaction is needed (PR:N/UI:N). The primary limiting factors are therefore deployment-specific: the server must use the Python (not Rust) frontend, must serve a Qwen video model, and must expose /tokenize to the attacker; instances serving text-only or non-Qwen-VL models, or using the Rust frontend, are not exploitable. |
| Impact | This is a medium-severity, availability-only denial-of-service issue, and the signals are largely consistent rather than conflicting. The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, 5.3) describes a remotely reachable, low-complexity, unauthenticated attack affecting only availability, which matches the description: an unauthenticated caller submits oversized media_io_kwargs.video values to the /tokenize endpoint to exhaust frontend memory and potentially crash the API process (CWE-770, resource allocation without limits). There is no CVSS/description contradiction on reachability - both agree it is network-reachable and unauthenticated. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so there is no evidence of active exploitation or weaponization; this sits in the 'patch in normal cycle' tier rather than emergency. The one nuance a defender should verify: the vendor rated availability impact as A:L, but the description says the attack can 'terminate the API process,' which is a full outage of the affected instance - repeated or scripted requests could plausibly justify A:H in some deployments, so the real-world availability impact may be slightly understated. Exploitation is also gated on a specific configuration (see exploitation_conditions), which meaningfully narrows who is actually at risk below what a raw AV:N/PR:N vector implies. |
| Exploit ScenarioDerived | An attacker with network reachability to a vLLM Python-frontend instance serving a Qwen2-VL or Qwen3-VL video-capable model sends an unauthenticated POST to /tokenize containing media_io_kwargs.video.max_frames and .fps set far above sane limits, plus an attacker-controlled video reference. The sampler decodes every selected frame, ballooning frontend memory before any scheduling or admission control runs, and repeated requests can terminate the API process. No public exploit code was identified at time of analysis, and because low attack complexity requires no special timing, a trivial script could reproduce it against a vulnerable configuration. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
Unauthenticated denial of service in vLLM 0.24.0 through 0.29.x allows a remote caller to force excessive video frame decoding by supplying uncapped media_io_kwargs.video.max_frames and media_io_kwargs.video.fps values to the /tokenize endpoint, exhausting Python-frontend memory and potentially terminating the API process before scheduling or admission control. Only deployments using the Python frontend and serving Qwen2-VL or Qwen3-VL video-capable multimodal models via Qwen2VLVideoBackend or Qwen3VLVideoBackend are affected; the Rust frontend rejects the media_io_kwargs field. No public exploit has been identified at time of analysis, and the vendor has released a fix in vLLM 0.30.0.
RemediationAI
Upgrade to vLLM 0.30.0, which applies fixed class-level ceilings of 768 frames and 30 FPS in Qwen2VLVideoBackend and Qwen3VLVideoBackend via commit ea723c81c3ea26425cb69503a5d5e90822a04a45 and is documented in GHSA-x6mc-67gf-chw4. If upgrading immediately is not possible, switch to the Rust frontend, which rejects the media_io_kwargs field and is therefore not vulnerable, at the cost of any feature differences between the Rust and Python frontends. Alternatively, restrict access to the /tokenize endpoint so only trusted clients can reach it, using network ACLs, a reverse proxy, or an authentication layer, with the trade-off that legitimate tokenization clients will be blocked unless allowlisted. A reverse proxy can also strip or cap media_io_kwargs.video.max_frames and media_io_kwargs.video.fps in incoming requests, with the trade-off that legitimate high-frame-count or high-FPS video requests will be truncated or rejected. Avoid exposing /tokenize publicly while unpatched.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
This is an allocation-of-resources-without-limits or throttling weakness (CWE-770) in vLLM's multimodal video processing pipeline. The Qwen2VLVideoBackend and Qwen3VLVideoBackend classes compute which frames to sample from video input, and before the fix they read max_frames and fps directly from request-level media_io_kwargs without applying server-side ceilings. Because /tokenize accepts these values, an attacker who also supplies attacker-controlled video content can cause the sampler to decode every frame selected, consuming disproportionate frontend memory before scheduling or admission control and potentially terminating the API process. The upstream fix commit ea723c81c3ea26425cb69503a5d5e90822a04a45 adds class-level constants _MAX_FRAMES = 768 and _MAX_FPS = 30 and clamps request-supplied values using min(), so effective frame and FPS limits cannot exceed those thresholds. The Rust frontend is unaffected because it rejects the media_io_kwargs field entirely.
Know when Vllm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Remotely reachable /tokenize endpoint with no auth or interaction (AV:N/AC:L/PR:N/UI:N); only availability is affected via memory exhaustion (A:L, C:N/I:N), scope unchanged.
Primary rating from Vendor (github).
CVSS VectorVendor: github
DescriptionCVE.org
vLLM is an inference and serving engine for large language models. From 0.24.0 until 0.30.0, the Qwen2VLVideoBackend and Qwen3VLVideoBackend classes accept request-level values for the media_io_kwargs.video.max_frames and media_io_kwargs.video.fps fields without enforcing server-side ceilings. An unauthenticated caller can submit these values to the /tokenize endpoint, causing the sampler to decode every frame selected from attacker-controlled video input, consume disproportionate frontend memory, and potentially terminate the API process before scheduling or admission control. The Rust frontend is not affected because it rejects the media_io_kwargs field. This issue is fixed in version 0.30.0.
Blast Radius
ecosystem impact- 4 pypi packages depend on vllm (4 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.24.0.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Affected Products (CPE)CVE.org
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the sh
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
GHSA-x6mc-67gf-chw4
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB