CVE-2026-55646: vLLM Audio API Memory Exhaustion Denial of Service

Technical summary

The vulnerability stems from improper resource validation order in the audio processing pipeline. The /v1/audio/transcriptions and /v1/audio/translations endpoints call request.file.read() to fully materialize the uploaded multipart form data into memory before the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB limit (default 25 MB) is enforced in the downstream speech-to-text preprocessing layer. This creates a resource exhaustion window where an authenticated caller can submit files of arbitrary size, triggering unbounded memory allocation. The vulnerability affects both CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling), as the server fails to validate upload size before materialization and lacks safeguards against oversized requests.

Business impact

For organizations running vLLM as an inference service, this vulnerability can disrupt availability of speech-enabled AI applications. An authenticated internal user or a compromised client application with API access can trigger service outages by submitting large audio uploads, effectively denying service to legitimate users. In containerized or resource-constrained deployments (common in cloud environments), a single malicious request can exhaust allocated memory and terminate the vLLM process, requiring manual restart and causing user-facing downtime. The attack requires authentication, limiting exposure to trusted API consumers, but internal threat actors or compromised integrations pose significant risk.

Affected systems

vLLM version 0.22.0 through 0.23.0 are affected. Organizations using 0.24.0 or later are not vulnerable. The vulnerability is specific to deployments exposing the audio transcription and translation API routes; organizations using vLLM solely for text-based inference are unaffected. The risk profile depends on deployment configuration—services with generous memory allocation and auto-restart mechanisms face lower impact than those in tightly resource-constrained environments.

Exploitability

The vulnerability requires authentication (CVSS vector includes PR:L), meaning the attacker must possess valid API credentials or a valid session. The attack is trivial to execute once authenticated—simply uploading an oversized audio file via the REST API triggers the condition. No special tooling, race conditions, or complex exploitation steps are needed. The barrier to exploitation is low among trusted users or through compromised API keys, making this a moderate-risk vector for internal threat scenarios.

Remediation

Upgrade vLLM to version 0.24.0 or later, which implements size validation before file materialization. This is the definitive fix. Organizations unable to immediately upgrade should implement network-level controls: restrict access to /v1/audio/transcriptions and /v1/audio/translations endpoints to trusted internal services only, disable these routes entirely if audio functionality is not required, and deploy request size limits at the API gateway or load balancer level (enforce the 25 MB default or your organization's chosen limit upstream). Monitor vLLM memory usage and establish alerts for abnormal memory consumption patterns.

Patch guidance

Verify your vLLM version by checking the output of `python -c "import vllm; print(vllm.__version__)"`. If running 0.22.0 through 0.23.0, plan an upgrade to 0.24.0 or the latest available version. Review the vLLM release notes to confirm the audio-related fixes are included. Test the upgrade in a non-production environment with your audio workloads to ensure compatibility. If upgrading is blocked by other constraints, implement compensating controls (network isolation, request size limits at the gateway) immediately.

Detection guidance

Monitor vLLM logs for rejected audio requests with file size violations. Enable debug logging for the audio transcription pipeline to capture size-check failures. Watch system metrics (memory usage, process restarts) on vLLM instances; unexpected spikes or process terminations during audio requests suggest exploitation attempts. At the API gateway or reverse proxy level, log all POST requests to /v1/audio/transcriptions and /v1/audio/translations, including Content-Length headers. Unusual Content-Length values (significantly above 25 MB or your configured limit) warrant investigation. If using container orchestration, monitor for vLLM pod restarts or OOMKilled events coinciding with API traffic.

Why prioritize this

This vulnerability merits prompt but not emergency remediation. The CVSS score of 6.5 (MEDIUM) reflects that it requires authentication and causes availability impact only, not confidentiality or integrity compromise. However, it is easily exploited once an attacker has API access, and organizations with resource-constrained deployments face real operational risk. Prioritize patching if audio transcription/translation is business-critical or if your vLLM deployment runs in tight resource limits. In low-risk internal deployments with ample memory, it can be included in regular maintenance windows. The absence of active exploitation in the wild (not on CISA KEV list) supports a measured rather than emergency response.

Risk score, explained

CVSS 6.5 reflects: Network attack vector (AV:N) and low attack complexity (AC:L) indicate easy exploitation; however, authentication is required (PR:L), limiting the attacker population. Availability impact is High (A:H) because the service can be crashed or severely degraded; there is no confidentiality or integrity impact (C:N, I:N). The user interaction requirement is None (UI:N), and scope is Unchanged (S:U). The score appropriately weights this as a moderate-severity DoS that is dangerous primarily to organizations with sensitive deployments or adversarial internal users.

Frequently asked questions