EUVD-2026-41914
GHSA-v82g-2437-67m2
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Network-reachable via HTTP API; requires authenticated low-privilege credentials (PR:L); no confidentiality or integrity impact, only availability exhaustion via uncontrolled memory allocation.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2Blast Radius
ecosystem impact- 1 pypi packages depend on vllm (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.22.0.
DescriptionCVE.org
vLLM is an inference and serving engine for large language models. From 0.22.0 to 0.23.0, the /v1/audio/transcriptions and /v1/audio/translations routes call request.file.read() to fully materialize an uploaded audio file into memory before vLLM checks the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed upload size limit (default 25 MB) later in the speech-to-text preprocessing step, so an API caller who can reach those routes can submit an oversized multipart upload and cause vLLM to allocate memory proportional to the uploaded file size before the request is rejected as too large, creating memory pressure or terminating the process depending on deployment resource limits. This issue is fixed in version 0.24.0.
AnalysisAI
Memory exhaustion in vLLM 0.22.0-0.23.0 allows authenticated API callers to crash or destabilize the inference server by uploading arbitrarily large audio files. The /v1/audio/transcriptions and /v1/audio/translations endpoints invoke request.file.read() to fully buffer multipart uploads into process memory before the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB size guard is evaluated, meaning the size limit is checked only after the damage is done. No public exploit is identified at time of analysis; vendor-confirmed fix is available in version 0.24.0.
Technical ContextAI
vLLM implements OpenAI-compatible REST API endpoints, including audio transcription and translation routes backed by speech-to-text model preprocessing. The flaw (CWE-400, Uncontrolled Resource Consumption) arises from incorrect ordering of I/O and validation: the framework calls request.file.read() to materialize the uploaded multipart stream fully into heap memory, and only afterward invokes the preprocessing step that enforces the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed-file limit (defaulting to 25 MB). Because memory allocation precedes validation, the guard is functionally bypassed for the purpose of resource protection. The affected CPE is cpe:2.3:a:vllm-project:vllm:*:*:*:*:*:*:*:* across versions 0.22.0 through 0.23.0. The root cause is a classic TOCTOU-adjacent pattern: resource consumption happens before the consumption limit is checked.
RemediationAI
The primary remediation is upgrading to vLLM 0.24.0, where the fix is confirmed in commit b997071ec493765abbed990c65843ed05e4708a8 (see https://github.com/vllm-project/vllm/commit/b997071ec493765abbed990c65843ed05e4708a8) and pull request https://github.com/vllm-project/vllm/pull/45510. If immediate upgrade is not feasible, operators should disable or block access to the /v1/audio/transcriptions and /v1/audio/translations routes at the API gateway or reverse proxy layer (e.g., Nginx location deny rules or WAF path-based blocking) - note this disables audio transcription functionality entirely. As a secondary compensating control, configure hard memory limits on the vLLM process via container resource limits (e.g., Kubernetes resources.limits.memory) or cgroups to bound the blast radius of a successful attack to an OOM-kill rather than host-wide memory starvation; this does not prevent exploitation but limits its scope. Reducing VLLM_MAX_AUDIO_CLIP_FILESIZE_MB does not address the pre-validation allocation issue and should not be relied upon as a standalone mitigation.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Vllm versions up to 0.12.0 is affected by allocation of resources without limits or throttling (CVSS 6.5).
Race condition in vLLM's prompt embedding loader allows concurrent API requests to bypass the sparse tensor invariant gu
Remote code execution in vLLM 0.10.1 through 0.13.x lets an attacker who controls the model repository or path run arbit
Server-Side Request Forgery in vLLM's multimodal MediaConnector allows remote attackers to coerce the inference server i
Denial of service in vllm 0.19.0's OpenAI-compatible serving path allows remote unauthenticated attackers to exhaust sch
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today