{"id":"CVE-2026-100650","revision":"8697e7d3657e4855a731bfa4e90df992","records":[{"revision":"8697e7d3657e4855a731bfa4e90df992","observedAt":"2026-10-23T15:48:27.903+00:00","statement":{"source":"cve-program","id":"CVE-2026-100650","aliases":[],"title":"vLLM before 0.29.0 Resource Exhaustion via Unbounded Media Materialization","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.","state":0,"publishedAt":"2026-09-26T13:23:20.418+00:00","modifiedAt":"2026-10-01T11:06:44.741+00:00","affected":[{"ecosystem":"Vendor product","name":"vllm","ranges":[],"versions":[],"rawVersionEvidence":"{\n                    \"vendor\": \"vllm-project\",\n                    \"product\": \"vllm\",\n                    \"defaultStatus\": \"unaffected\",\n                    \"packageURL\": \"pkg:pypi/vllm\",\n                    \"versions\": [\n                        {\n                            \"version\": \"0\",\n                            \"status\": \"affected\",\n                            \"versionType\": \"semver\",\n                            \"lessThan\": \"0.29.0\"\n                        },\n                        {\n                            \"version\": \"0.29.0\",\n                            \"status\": \"unaffected\",\n                            \"versionType\": \"semver\"\n                        }\n                    ]\n                }"}],"metrics":[{"system":"CVSS 4.0","vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","score":7.1,"severity":"HIGH"},{"system":"CVSS 3.1","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":6.5,"severity":"MEDIUM"}],"references":["https://github.com/vllm-project/vllm/security/advisories/GHSA-p6g9-7v3x-m8mv","https://github.com/vllm-project/vllm/commit/752a3a504485790a2e8491cacbb35c137339ad34","https://www.vulncheck.com/advisories/vllm-before-0.29.0-resource-exhaustion-via-unbounded-media-materialization"],"sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-100650","license":"CVE Program Terms of Use","key":"cve-program:CVE-2026-100650","identifiers":["CVE-2026-100650"]},"retained":false,"historicalAffected":[]}],"coverage":[]}