CVE-2026-100650: vLLM Media Processing DOS Vulnerability

CVE-2026-100650 Overview

CVE-2026-100650 is a resource exhaustion vulnerability in vLLM through version 0.29.0. The server fetches and fully materializes remote or inline media before enforcing its documented media controls. These controls include the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB cap (default 25 MB) and the per-modality --limit-mm-per-prompt item limits.

Four ingress paths are affected: the shared media-acquisition layer, the chat completions audio_url/base64 path, the batch speech runner, and the Rust frontend POST /tokenize route. A remote attacker can force the API server or batch-runner process to allocate memory and consume outbound bandwidth proportional to an attacker-chosen body size before the request is rejected. The result is pre-inference memory and bandwidth exhaustion (denial of service) categorized under [CWE-400].

Critical Impact
Remote attackers can exhaust memory and outbound bandwidth of vLLM API server and batch runner processes, causing denial of service without authentication on the Rust /tokenize route.

Affected Products

vLLM versions through 0.29.0
vLLM Rust frontend POST /tokenize route (unauthenticated by design)
vLLM OpenAI-compatible chat completions and batch speech runner surfaces

Discovery Timeline

2026-09-26 - CVE-2026-100650 published to NVD
2026-09-30 - Last updated in NVD database

Technical Details for CVE-2026-100650

Vulnerability Analysis

vLLM accepts media content (audio, images) via multiple API surfaces that reference remote URLs or inline base64 payloads. The documented controls — VLLM_MAX_AUDIO_CLIP_FILESIZE_MB and --limit-mm-per-prompt — are intended to bound memory and bandwidth consumption per request.

The server inverts the order of operations. It reads the entire HTTP response body through HTTPConnection.get_bytes() and async_get_bytes(), base64-decodes inline payloads, or spawns one fetch/decode task per media part. Size and item-count checks execute only after this materialization completes. On some paths, the checks never execute at all.

An attacker submitting an audio_url pointing to a multi-gigabyte resource, or an inline base64 payload orders of magnitude larger than the configured cap, forces the server to buffer the full content before rejection. The impact is denial of service only — no code execution or data disclosure occurs.

Root Cause

The root cause is a time-of-check versus time-of-use ordering flaw in the media-acquisition layer. Enforcement of VLLM_MAX_AUDIO_CLIP_FILESIZE_MB and --limit-mm-per-prompt occurs after get_bytes()/async_get_bytes() returns, rather than during streaming via a byte counter with early termination. Per-modality item limits similarly apply after parallel fetch/decode tasks have already been scheduled.

Attack Vector

The chat completions and batch surfaces require an API key when one is configured, limiting those paths to authenticated attackers (PR:L). The Rust frontend POST /tokenize route is unauthenticated by design and reachable by any network client with connectivity to the server. Exploitation requires no user interaction and uses standard HTTP requests containing oversized media references or inline payloads.

python

# Patch excerpt from upstream commit 752a3a5
# Source: https://github.com/vllm-project/vllm/commit/752a3a504485790a2e8491cacbb35c137339ad34
        pm.register_replacement(
            pattern,
            replacement,
            self.get_inputs(),
            pm.fwd_only,
            pm_pass,
            extra_check=_norm_input_weight_dtype_match,
        )

Source: GitHub Commit 752a3a5

Detection Methods for CVE-2026-100650

Indicators of Compromise

Sudden memory spikes in vLLM API server or batch-runner processes correlated with inbound requests containing audio_url or large base64 payloads
Elevated outbound bandwidth to attacker-controlled hosts following inbound requests to /v1/chat/completions or /tokenize
HTTP 4xx responses issued after unusually long request processing times, indicating materialization completed before rejection
Repeated requests to the Rust frontend POST /tokenize route from a single source IP

Detection Strategies

Monitor process-level RSS (resident set size) for vLLM workers and alert on growth exceeding configured VLLM_MAX_AUDIO_CLIP_FILESIZE_MB thresholds
Correlate request payload sizes and Content-Length headers of fetched remote media against the configured per-modality limits
Instrument reverse proxies in front of vLLM to log request body sizes, media URLs referenced, and outbound fetch sizes

Monitoring Recommendations

Collect vLLM server logs, egress firewall logs, and process metrics into a centralized data lake for correlation
Baseline normal media payload sizes per tenant or API key, and alert on statistical outliers
Track OOM-killer events and container restarts on hosts running vLLM workers

How to Mitigate CVE-2026-100650

Immediate Actions Required

Upgrade vLLM to version 0.29.0 or later, which contains the enforcement fix
Place vLLM API endpoints behind an authenticating reverse proxy, especially the Rust frontend /tokenize route
Enforce request body size limits and connection timeouts at the reverse proxy (for example, nginx client_max_body_size)
Restrict outbound network access from vLLM workers to prevent arbitrary remote media fetches

Patch Information

The upstream fix is tracked in the vLLM project. Refer to the GitHub Security Advisory GHSA-p6g9-7v3x-m8mv and the VulnCheck Resource Exhaustion Advisory for version and patch details. Operators should upgrade to the first vLLM release that includes the ordering fix for media size and item-count enforcement.

Workarounds

Deploy a reverse proxy (nginx, Envoy) in front of vLLM with strict body-size and rate limits on /v1/chat/completions and /tokenize
Disable or firewall off the Rust frontend /tokenize route if it is not required by downstream consumers
Require API key authentication on all exposed endpoints and allowlist source IP ranges
Run vLLM workers with cgroup memory limits so OOM events contain damage to a single worker rather than the host

bash

# nginx reverse-proxy mitigation example
http {
    client_max_body_size 2m;
    client_body_timeout 10s;

    limit_req_zone $binary_remote_addr zone=vllm:10m rate=10r/s;

    server {
        listen 443 ssl;
        location /tokenize {
            limit_req zone=vllm burst=5 nodelay;
            proxy_pass http://vllm_backend;
        }
        location /v1/chat/completions {
            limit_req zone=vllm burst=5 nodelay;
            proxy_pass http://vllm_backend;
        }
    }
}