CVE-2026-100650: vLLM before 0.29.0 Resource Exhaustion via Unbounded Media Materialization
vLLM through 0.29.0 fetches and fully materializes remote or inline media before enforcing its documented media controls (the VLLMMAXAUDIOCLIPFILESIZEMB compressed-audio size cap, default 25 MB, and the per-modality --limit-mm-per-prompt item limits). Across four ingress paths — the shared media-acquisition layer (HTTPConnection.getbytes()/asyncgetbytes()), the chat completions audiourl/base64 path, the batch speech runner, and the Rust frontend POST /tokenize route — the server reads the entire HTTP response body, base64-decodes the inline payload, or spawns one fetch/decode task per media part, and only then applies the limit (or, on some paths, never applies it). A remote attacker can therefore cause the API server or batch-runner process to allocate memory and consume outbound bandwidth proportional to an attacker-chosen body size or media item count before the request is rejected, resulting in pre-inference memory and bandwidth exhaustion (denial of service). The chat and batch surfaces require an API key when one is configured; the Rust frontend /tokenize route is unauthenticated by design. There is no code execution or data disclosure impact.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Configure the compressed-audio size cap using VLLM_MAX_AUDIO_CLIP_FILESIZE_MB; the documented default is 25 MB.
vLLM VLLM_MAX_AUDIO_CLIP_FILESIZE_MB = 25 MB - Configuration
Configure per-modality --limit-mm-per-prompt item limits for each prompt.
vLLM --limit-mm-per-prompt = Per-modality item limits
Event History
Frequently Asked Questions
Which deployments are exposed without credentials?
The Rust frontend POST /tokenize route is unauthenticated by design. Chat completions and batch surfaces require an API key only when one has been configured.
What does an attacker need to send to trigger the denial of service?
An attacker can supply an oversized remote media response or inline base64 media payload, or use a large number of media items. The affected paths fetch, decode, or create work for the media before enforcing size or per-prompt limits.
Are the documented media limits sufficient protection on affected versions?
No. The compressed-audio size cap and per-modality item limits are applied only after materialization on affected paths, and some paths may not apply them at all. Memory allocation and outbound bandwidth consumption can therefore occur before rejection.
What impact should responders expect?
The issue can exhaust memory and outbound bandwidth in the API server or batch-runner process before inference, causing denial of service. The provided data indicates no code execution or data disclosure impact.