AI Threat AlertvLLM, a widely used LLM inference server, has a resource-exhaustion flaw: a caller can pass the request-level media_io_kwargs field to select the GLMGA video backend with huge fps and max_frames values. A tiny, valid video then makes the server build an attacker-sized frame-index list, which consumes disproportionate CPU and memory in the shared media-loading executor. The CVSS score is a moderate 5.3, availability-only, with no authentication or user interaction needed. EPSS is low (0.30%, top 79th percentile), there is no public exploit, no Nuclei template and no CISA KEV listing. Even so, vLLM has 95 downstream dependents and 123 other tracked CVEs, so internet-exposed multimodal endpoints are a realistic target for cheap degradation of a GPU-backed service. Upgrade to vLLM 0.30.0 or later (affected range: >= 0.23.0rc2, < 0.30.0). Until then, block or sanitize client-supplied media_io_kwargs at the gateway and enforce request-level rate limits.
What is the risk?
Low-to-medium overall risk. Exploitation is trivial (network, no privileges, no user interaction), but impact is limited to availability (A:L) with no confidentiality or integrity loss. Exploitation probability is low (EPSS 0.00302), with no public PoC, scanner template or KEV listing. Risk rises for internet-facing or multi-tenant vLLM deployments that accept multimodal and video input from untrusted callers, because the shared media-loading executor can starve legitimate requests. Self-hosted instances behind authenticated gateways carry a lower exposure.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | >= 0.23.0rc2, < 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 in PR #54935, commit 8b6de0eb). 2) Until patched, strip or allowlist the media_io_kwargs field at the API gateway or reverse proxy, and reject or cap fps and max_frames values. 3) Disable video input, or the GLMGA backend, if it is not needed. 4) Enforce authentication, per-client rate limits and request-size and timeout limits on inference endpoints. 5) Monitor CPU, memory and media-loader executor queue depth, and alert on requests carrying unusually large fps or max_frames values. 6) Run vLLM with container memory and CPU limits so an abusive request cannot take down the host.
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-105760?
vLLM, a widely used LLM inference server, has a resource-exhaustion flaw: a caller can pass the request-level media_io_kwargs field to select the GLMGA video backend with huge fps and max_frames values. A tiny, valid video then makes the server build an attacker-sized frame-index list, which consumes disproportionate CPU and memory in the shared media-loading executor. The CVSS score is a moderate 5.3, availability-only, with no authentication or user interaction needed. EPSS is low (0.30%, top 79th percentile), there is no public exploit, no Nuclei template and no CISA KEV listing. Even so, vLLM has 95 downstream dependents and 123 other tracked CVEs, so internet-exposed multimodal endpoints are a realistic target for cheap degradation of a GPU-backed service. Upgrade to vLLM 0.30.0 or later (affected range: >= 0.23.0rc2, < 0.30.0). Until then, block or sanitize client-supplied media_io_kwargs at the gateway and enforce request-level rate limits.
Is CVE-2026-105760 actively exploited?
No confirmed active exploitation of CVE-2026-105760 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-105760?
1) Upgrade vLLM to 0.30.0 or later (fix in PR #54935, commit 8b6de0eb). 2) Until patched, strip or allowlist the media_io_kwargs field at the API gateway or reverse proxy, and reject or cap fps and max_frames values. 3) Disable video input, or the GLMGA backend, if it is not needed. 4) Enforce authentication, per-client rate limits and request-size and timeout limits on inference endpoints. 5) Monitor CPU, memory and media-loader executor queue depth, and alert on requests carrying unusually large fps or max_frames values. 6) Run vLLM with container memory and CPU limits so an abusive request cannot take down the host.
What systems are affected by CVE-2026-105760?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference endpoints, multimodal (video) pipelines, multi-tenant inference gateways.
What is the CVSS score for CVE-2026-105760?
CVE-2026-105760 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.T0040AI Model Inference API AccessCompliance Controls Affected
What are the technical details?
Original Advisory
vLLM is an inference and serving engine for large language models. Prior to 0.30.0, a caller can use the request-level media_io_kwargs field to select the GLMGA video backend and supply large values for the fps and max_frames options without a strict work ceiling. GLMGA constructs and deduplicates an attacker-sized pre-decode frame-index list, allowing a compact request and tiny valid video to consume disproportionate CPU time and memory in the shared media-loading executor. This issue is fixed in version 0.30.0.
Exploitation Scenario
An attacker finds an exposed vLLM OpenAI-compatible endpoint that serves a video-capable model. They send repeated small requests with a tiny valid video and a media_io_kwargs payload selecting the GLMGA backend with very large fps and max_frames values. Each request forces the server to build and deduplicate a huge frame-index list, saturating the shared media-loading executor and exhausting memory. Legitimate users then see timeouts and errors, or the worker is OOM-killed, and the GPU capacity the operator pays for sits idle.
Weaknesses (CWE)
CWE-400Uncontrolled Resource ConsumptionPrimaryCWE-400Uncontrolled Resource ConsumptionPrimaryCWE-400Uncontrolled Resource ConsumptionCWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.
- [Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- [Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
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