CVE-2026-105760: vLLM Inference Engine DOS Vulnerability

CVE-2026-105760 Overview

CVE-2026-105760 is a resource exhaustion vulnerability [CWE-400] in vLLM, an inference and serving engine for large language models. Versions prior to 0.30.0 allow a remote caller to abuse the request-level media_io_kwargs field to select the GLMGA video backend and supply unbounded values for fps and max_frames. GLMGA then constructs and deduplicates an attacker-sized pre-decode frame-index list, letting a compact request and a tiny valid video consume disproportionate CPU time and memory in the shared media-loading executor. The issue is fixed in vLLM version 0.30.0.

Critical Impact
An unauthenticated network attacker can degrade or disrupt availability of a vLLM inference service by issuing small requests that force the shared media executor to allocate and process oversized frame-index lists.

Affected Products

vLLM inference and serving engine prior to version 0.30.0
Deployments that expose the GLMGA video backend via the media_io_kwargs request field
Multi-tenant vLLM instances sharing a media-loading executor

Discovery Timeline

2026-10-05 - CVE-2026-105760 published to NVD
2026-10-06 - Last updated in NVD database
vLLM v0.30.0 - Patch released capping GLMGA frames and FPS

Technical Details for CVE-2026-105760

Vulnerability Analysis

The vulnerability lives in the GLMGA video backend inside vLLM's multimodal media loader. When a request references a video and sets media_io_kwargs to select the GLMGA backend, the backend trusts caller-supplied fps and max_frames values without applying a work ceiling. GLMGA then computes a pre-decode frame-index list sized by those parameters and deduplicates it before any decode work begins.

Because the list is built in memory and processed on the shared media-loading executor, a single compact HTTP request paired with a small valid video is sufficient to monopolize CPU and memory. Other tenants and inference requests sharing that executor experience latency spikes, timeouts, or outright failures. The confidentiality and integrity of model data are not affected, but service availability degrades for the duration of the attack.

Root Cause

The root cause is missing bounds enforcement on request-controlled parameters in the GLMGA backend path. The code accepted fps and max_frames from media_io_kwargs and used them to size an index list without validating that the resulting work fit within a safe ceiling. This is a classic uncontrolled resource consumption pattern [CWE-400].

Attack Vector

Exploitation requires only network access to a vulnerable vLLM endpoint that accepts multimodal video input. No authentication or user interaction is needed. The attacker submits an inference request with a tiny valid video and media_io_kwargs crafted to invoke the GLMGA backend with large fps and max_frames values. Repeating the request amplifies pressure on the shared executor.

python

     video_processor="GlmgaVideoProcessor",
 )
 class GLMGAVideoBackend(VideoBackend):
+    _MAX_FRAMES: ClassVar[int] = 640
+    _MAX_FPS: ClassVar[int] = 30
+
     @classmethod
     def _prepare_source(cls, source: VideoSourceMetadata) -> VideoSourceMetadata:
         # Estimate duration from frame count and fps when the container

Source: vLLM commit 8b6de0e. The patch introduces class-level constants _MAX_FRAMES = 640 and _MAX_FPS = 30 to cap GLMGA sampling and prevent request-driven resource exhaustion.

Detection Methods for CVE-2026-105760

Indicators of Compromise

Inference requests containing media_io_kwargs with GLMGA backend selection and abnormally large fps or max_frames values
Sustained spikes in CPU and resident memory on vLLM worker processes handling video inputs
Rising queue depth, request timeouts, or 5xx responses from the vLLM media-loading executor

Detection Strategies

Inspect application and reverse-proxy logs for request bodies that set media_io_kwargs.video_backend to GLMGA with high numeric parameters
Alert on vLLM worker memory or CPU utilization crossing a baseline threshold while serving multimodal requests
Correlate small-payload inbound requests with disproportionate server-side processing time on the /generate or multimodal inference endpoints

Monitoring Recommendations

Export vLLM runtime metrics for executor queue length, per-request latency, and worker memory to your observability platform
Rate-limit and log multimodal video requests per client identity at the API gateway
Capture full request parameters for multimodal endpoints to enable retrospective hunting

How to Mitigate CVE-2026-105760

Immediate Actions Required

Upgrade vLLM to version 0.30.0 or later on all inference nodes
Audit exposed vLLM endpoints and restrict network reachability to trusted clients where feasible
Review API gateway rules to reject requests specifying unexpected media_io_kwargs fields

Patch Information

The fix is included in vLLM Release v0.30.0 via Pull Request #54935 and commit 8b6de0e. The patch caps GLMGA sampling at 640 frames and 30 FPS. Full details are in the GitHub Security Advisory GHSA-58v5-2m8f-94pr.

Workarounds

Disable the GLMGA video backend in deployments that do not require it
Enforce request-size and parameter validation at a reverse proxy to cap fps and max_frames values before they reach vLLM
Isolate multimodal workloads on dedicated executors to limit blast radius on other tenants

bash

# Upgrade vLLM to the patched release
pip install --upgrade "vllm>=0.30.0"

# Verify installed version
python -c "import vllm; print(vllm.__version__)"