vLLM CVE-2026-105760

Exploitation requires a vLLM deployment prior to 0.30.0 that serves a video-capable multimodal model and honors request-level media_io_kwargs, with the attacker selecting the GLMGA video backend and supplying large fps and max_frames values (the pre-patch code defaulted max_frames to 640 with no hard class ceiling and applied target.fps directly). A tiny valid video file is sufficient to trigger the oversized frame-index allocation. Limiting factors: only instances configured to accept video/multimodal input through the GLMGA backend are affected; deployments not exposing video inference, or already on 0.30.0 (which clamps target_fps to _MAX_FPS=30, caps max_frames at _MAX_FRAMES=640, and bounds extract_t by total_frames_num), are not exploitable. The CVSS vector reports PR:N, so no authentication is required, making any network-reachable vulnerable endpoint exposed.

This is a moderate-severity, resource-exhaustion denial-of-service issue (CWE-400) with a CVSS of 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L). The vector is self-consistent with the description: a network-reachable caller sets the request-level media_io_kwargs field to select the GLMGA video backend and supplies oversized fps/max_frames values, with no privileges or user interaction required. Impact is availability-only and rated Low (A:L), because the GLMGA backend builds an attacker-sized pre-decode frame-index list that disproportionately consumes CPU and memory in the shared media-loading executor - degrading or starving the shared serving process rather than fully crashing a host or exposing data. No EPSS score was provided in the input, the issue is not listed in CISA KEV, and no public proof-of-concept is referenced (only the fix commit, PR, release, and GHSA advisory), so there is no public exploit identified at time of analysis and no evidence of active exploitation. No SSVC decision data was supplied. The signals are therefore consistent rather than conflicting: a genuine but bounded availability risk that is realistic to trigger (low complexity, unauthenticated) but limited to deployments actually serving video multimodal input through the GLMGA backend. Treat as a patch-soon hardening fix rather than an emergency; prioritize higher if the affected vLLM endpoint is internet-exposed and accepts multimodal requests.

An attacker with network access to a vulnerable vLLM endpoint serving a video-capable multimodal model submits a compact inference request containing a tiny valid video plus media_io_kwargs selecting the GLMGA backend with extreme fps and max_frames values. GLMGA constructs and deduplicates a huge pre-decode frame-index list, causing a small request to consume disproportionate CPU and memory in the shared media-loading executor and degrading service for all co-located requests. No public exploit code is identified at time of analysis, but the fix commit and regression tests demonstrate the exact triggering parameters.