CVE-2026-55646 in vLLM
Summary
by MITRE • 07/06/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/06/2026
The vulnerability exists within the vLLM inference engine's audio processing endpoints, specifically affecting versions between 0.22.0 and 0.23.0. The flaw manifests in the /v1/audio/transcriptions and /v1/audio/translations API routes where the system executes request.file.read() to completely load uploaded audio files into memory prior to validating size constraints. This premature memory allocation occurs before the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB limit check, which defaults to 25 megabytes. The architectural design creates a critical timing issue where resource consumption precedes validation, allowing malicious or malformed requests to exhaust available memory before rejection occurs.
This vulnerability represents a classic resource exhaustion attack vector that falls under CWE-400 - Uncontrolled Resource Consumption and aligns with ATT&CK technique T1499.2 - Endpoint Denial of Service through resource depletion. The flaw enables an attacker to submit audio files larger than the intended limit, causing the system to allocate memory proportional to the actual file size rather than the validated maximum. When deployed in production environments with constrained resources, this behavior can lead to memory pressure that ultimately results in process termination or service disruption, creating a denial of service condition.
The operational impact extends beyond simple resource exhaustion, as it creates a window where the system consumes excessive memory before rejecting oversized requests. This timing discrepancy allows attackers to potentially overwhelm system resources and cause cascading failures in deployments where memory is limited or when multiple concurrent requests are processed. The vulnerability affects any deployment that accepts audio uploads through these specific API endpoints, making it particularly dangerous in multi-tenant environments or systems with strict resource limitations.
Mitigation strategies should focus on implementing proper input validation before memory allocation occurs. The fix implemented in version 0.24.0 addresses this by ensuring size limits are enforced prior to reading file contents into memory. Organizations should immediately upgrade to version 0.24.0 or later to resolve the vulnerability. Additionally, deploying rate limiting and request size monitoring can provide defensive measures against abuse while waiting for upgrades. System administrators should also implement memory monitoring and alerting to detect potential exploitation attempts that might cause service disruption through resource exhaustion attacks.