CVE-2026-100650
Received Received - Intake

Memory Exhaustion in vLLM Media Handling

Publication date: 2026-09-26

Last updated on: 2026-09-26

Assigner: VulnCheck

Description
vLLM through 0.29.0 fetches and fully materializes remote or inline media before enforcing its documented media controls (the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB 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.get_bytes()/async_get_bytes()), the chat completions audio_url/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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-09-26
Last Modified
2026-09-26
Generated
2026-09-26
AI Q&A
2026-09-26
EPSS Evaluated
N/A
NVD
CVE-2026-100650
EUVD
EUVD-2026-87744

Affected Vendors & Products

Showing 3 associated CPEs
Vendor Product Version / Range
vllm_project vllm 0.29.0
vllm_project vllm to 0.29.0 (exc)
vllm_project vllm 0.25.1

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-400 The product does not properly control the allocation and maintenance of a limited resource.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

vLLM through version 0.29.0 fails to enforce media size limits before fully processing remote or inline media. Attackers can exploit this by sending oversized media files or multiple media items, causing the server to consume excessive memory and bandwidth before rejecting the request. This leads to denial of service by exhausting system resources during the pre-inference stage.

Detection Guidance

Monitor for unusually high memory usage or bandwidth consumption during media processing in vLLM. Check for large HTTP responses or base64-decoded payloads being fully materialized before media controls are applied. Inspect logs for failed requests due to size limits being exceeded.

Impact Analysis

If you run a vLLM server, an attacker could send large media files or many small ones to crash your API server or batch-runner process. This disrupts service availability and may require restarting the service. The impact is limited to denial of service; no data is leaked or code executed.

Compliance Impact

This vulnerability primarily impacts availability, which may affect compliance with regulations requiring system uptime or data processing continuity. GDPR and HIPAA focus on confidentiality and integrity, so direct compliance impact is limited unless service disruption leads to secondary issues like delayed data access.

Mitigation Strategies

Upgrade vLLM to a version beyond 0.29.0 where media controls are enforced before full materialization. Implement network-level restrictions to limit request sizes. Add authentication to all ingress paths, including the Rust frontend /tokenize route. Monitor and rate-limit media-heavy requests.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-100650. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart