CVE-2026-105758: 
NixOS 취약성 분석 및 완화

CVE-2026-105758 is a denial-of-service vulnerability in vLLM, an inference and serving engine for large language models, caused by missing server-side resource limits on video sampling parameters in the Qwen2-VL and Qwen3-VL backends. Affecting vLLM versions >= 0.24.0 and < 0.30.0, the flaw allows unauthenticated remote attackers to exhaust API server memory by submitting arbitrarily large media_io_kwargs.video.max_frames and fps values to the /tokenize endpoint. The vulnerability was reported by Eva Crystal / 0xiviel (XSource Security), privately disclosed on September 23, 2026, and published to the GitHub Advisory Database on October 5, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory, Feedly).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the Qwen2VLVideoBackend and Qwen3VLVideoBackend classes in vllm/multimodal/video.py read max_frames and fps directly from the request-supplied media_io_kwargs dictionary without enforcing any server-side ceiling. Unlike other backends (e.g., GLMGAVideoBackend, which caps at _MAX_FRAMES=640 and _MAX_FPS=30), the Qwen samplers ignore the num_frames key entirely and use max_frames as the sole upper bound — which an attacker can set to an arbitrarily large value (e.g., 1e9). The vulnerable code path is reachable via unauthenticated HTTP POST to /tokenize and /invocations, as these endpoints are excluded from AuthenticationMiddleware even when --api-key is configured. An attacker can also explicitly select the qwen3_vl video backend on any deployment via the video_backend request field, making the attack applicable beyond Qwen-specific deployments (Github Advisory, vLLM PR #56729).

Successful exploitation causes memory exhaustion of the vLLM API server process, potentially terminating it before scheduling or admission control can intervene, which affects all tenants sharing the instance. Measured impact shows that 74 extra bytes of JSON in a 1.43 MiB request body drove server peak RSS from 2,271 MiB to 13,629 MiB; at larger video sizes, the process can be OOM-killed entirely. There is no confidentiality or integrity impact — the vulnerability is purely an availability (denial-of-service) issue. The --limit-mm-per-prompt flag does not mitigate this, as it bounds media items rather than frames within an item (Github Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation as of the advisory publication date (Feedly). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack requires no authentication, no special privileges, and no user interaction, making it trivially exploitable against any exposed vLLM instance serving Qwen2-VL or Qwen3-VL models with the Python frontend.

1. Reconnaissance: Identify internet-facing vLLM API servers (versions 0.24.0–0.29.x) using tools like Shodan or Censys, looking for services exposing the vLLM OpenAI-compatible API (default port 8000). Confirm the deployment serves a Qwen2-VL or Qwen3-VL model, or plan to specify video_backend: qwen3_vl explicitly.
2. Prepare a high-frame-count video payload: Craft or obtain a video file with a large number of frames (e.g., a long, high-FPS video). Encode it as a data: URI or host it at an attacker-controlled URL to bypass the VLLM_MAX_MEDIA_DOWNLOAD_SIZE_MB limit (which does not apply to data: URIs).
3. Craft the malicious request: Construct an HTTP POST request to /tokenize (or /invocations) with a JSON body that includes the video payload and sets media_io_kwargs.video.max_frames to a very large value (e.g., 1000000000) and media_io_kwargs.video.fps to a high value (e.g., 1000000). Optionally include video_backend: qwen3_vl to force the vulnerable sampler on non-Qwen deployments.
4. Submit the request: Send the unauthenticated POST request to the target server. The frontend will decode every frame selected by the attacker-controlled parameters before any scheduling or admission control runs.
5. Achieve denial of service: The server's memory consumption spikes dramatically (measured: 2,271 MiB → 13,629 MiB with 74 extra bytes of JSON), potentially triggering an OOM kill of the API process and denying service to all users of the instance (Github Advisory, vLLM PR #56729).

• Network: Unauthenticated HTTP POST requests to /tokenize or /invocations endpoints containing media_io_kwargs fields with abnormally large max_frames (e.g., > 768) or fps (e.g., > 30) values; large request bodies (>1 MiB) to these endpoints from unexpected sources.
• Logs: vLLM access logs showing repeated or large POST requests to /tokenize or /invocations with media_io_kwargs in the body; Python OOM kill messages in system logs (e.g., Out of memory: Killed process <pid> (python)).
• Process: Sudden spike in RSS/memory usage of the vLLM Python process followed by process termination; unexpected restart of the vLLM API server process.
• File System: No specific file artifacts expected, as the attack is entirely in-memory and transient.

Upgrade vLLM to version 0.30.0 or later, which applies class-level _MAX_FRAMES=768 and _MAX_FPS=30 caps to both Qwen2VLVideoBackend and Qwen3VLVideoBackend via commit ea723c8 (PR #56729), preventing request-level values from exceeding these ceilings (vLLM Release v0.30.0, vLLM PR #56729). If immediate patching is not possible, restrict network access to the /tokenize and /invocations endpoints using a reverse proxy or firewall rules, and implement external rate limiting and resource quotas on API requests containing video data. Note that configuring --api-key alone does not protect /tokenize or /invocations, as these endpoints are excluded from authentication middleware (Github Advisory).

The vulnerability was reported by Eva Crystal / 0xiviel (XSource Security) and coordinated by jperezdealgaba, who also authored the fix. The vLLM maintainer Isotr0py noted in the PR review that a more robust long-term solution would be making fps and max_frames static (non-overridable) kwargs, leaving the class-level cap as an interim measure pending further refactoring (vLLM PR #56729). Red Hat tracked the issue via Bugzilla and the advisory was picked up by GitLab's advisory database shortly after publication (Github Advisory).