AI Threat AlertCVE-2026-105758 is a resource-exhaustion flaw in vLLM (0.24.0 to before 0.30.0): the Qwen2-VL and Qwen3-VL video backends accept client-supplied max_frames and fps values on the unauthenticated /tokenize endpoint without any server-side ceiling. A single crafted request can force the frontend to decode a huge number of frames, exhaust memory and kill the API process before admission control ever sees it. Severity is medium (CVSS 5.3, availability-only), the EPSS is low (0.00308, though in the top 78th percentile), it is not in CISA KEV, and there is no public exploit or Nuclei template, so mass exploitation is unlikely today. Even so, the attack is trivial (network, no authentication, low complexity), vLLM has 95 downstream dependents and 123 other CVEs on record, and any internet-exposed multimodal inference service is a cheap target for outages. Upgrade to vLLM 0.30.0; if you can't do it right away, block or authenticate /tokenize and strip media_io_kwargs at the gateway.
What is the risk?
Medium overall. Exploitation is trivial (AV:N/AC:L/PR:N/UI:N) but impact is limited to availability (A:L); there is no confidentiality or integrity impact. Real-world risk rises sharply for internet-exposed vLLM deployments serving Qwen2-VL or Qwen3-VL video models without an authenticating gateway, because one request can crash the whole API process and cause an outage. No known active exploitation (not in KEV, no public PoC, no Nuclei template, EPSS 0.003).
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | >= 0.24.0, < 0.30.0 | 0.30.0 |
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.30.0 or later (fix: PR #56729, commit ea723c81). 2) Workaround: put /tokenize and the other multimodal endpoints behind authentication and a reverse proxy/API gateway; reject or strip media_io_kwargs.video.max_frames and media_io_kwargs.video.fps from request bodies; cap request size and per-client rate. 3) Set container/cgroup memory limits and automatic restarts so a crash is contained and recovers quickly. 4) Consider the Rust frontend, which rejects media_io_kwargs. 5) Detection: alert on /tokenize requests containing media_io_kwargs, on anomalous memory spikes or OOM kills of the vLLM API process, and on repeated restarts. 6) Inventory with pip show vllm to find versions 0.24.0 to 0.29.x.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-105758?
CVE-2026-105758 is a resource-exhaustion flaw in vLLM (0.24.0 to before 0.30.0): the Qwen2-VL and Qwen3-VL video backends accept client-supplied max_frames and fps values on the unauthenticated /tokenize endpoint without any server-side ceiling. A single crafted request can force the frontend to decode a huge number of frames, exhaust memory and kill the API process before admission control ever sees it. Severity is medium (CVSS 5.3, availability-only), the EPSS is low (0.00308, though in the top 78th percentile), it is not in CISA KEV, and there is no public exploit or Nuclei template, so mass exploitation is unlikely today. Even so, the attack is trivial (network, no authentication, low complexity), vLLM has 95 downstream dependents and 123 other CVEs on record, and any internet-exposed multimodal inference service is a cheap target for outages. Upgrade to vLLM 0.30.0; if you can't do it right away, block or authenticate /tokenize and strip media_io_kwargs at the gateway.
Is CVE-2026-105758 actively exploited?
No confirmed active exploitation of CVE-2026-105758 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-105758?
1) Upgrade vLLM to 0.30.0 or later (fix: PR #56729, commit ea723c81). 2) Workaround: put /tokenize and the other multimodal endpoints behind authentication and a reverse proxy/API gateway; reject or strip media_io_kwargs.video.max_frames and media_io_kwargs.video.fps from request bodies; cap request size and per-client rate. 3) Set container/cgroup memory limits and automatic restarts so a crash is contained and recovers quickly. 4) Consider the Rust frontend, which rejects media_io_kwargs. 5) Detection: alert on /tokenize requests containing media_io_kwargs, on anomalous memory spikes or OOM kills of the vLLM API process, and on repeated restarts. 6) Inventory with pip show vllm to find versions 0.24.0 to 0.29.x.
What systems are affected by CVE-2026-105758?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference, multimodal/video inference APIs, agent backends using vLLM.
What is the CVSS score for CVE-2026-105758?
CVE-2026-105758 has a CVSS v3.1 base score of 5.3 (MEDIUM). The EPSS exploitation probability is 0.30%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0034.001Resource-Intensive QueriesAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker discovers an internet-exposed vLLM endpoint serving a Qwen3-VL model. They send an unauthenticated POST to /tokenize with a long attacker-controlled video and media_io_kwargs.video set to a very high max_frames and fps. The frontend decodes every selected frame into memory, hits OOM and the API process is killed. Repeating the request in a loop keeps the service down, interrupting all downstream applications, agents and customers that rely on the inference service.
Weaknesses (CWE)
CWE-770Allocation of Resources Without Limits or ThrottlingPrimaryCWE-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:N/UI:N/S:U/C:N/I:N/A:LReferences
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