CVE-2026-55646: Remote Denial of Service via Memory Exhaustion in vLLM Speech-to-Text Endpoints

The vLLM framework is an open-source serving engine optimized for high-throughput and memory-efficient Large Language Model (LLM) inference. In versions 0.22.0 through 0.23.0, the framework includes speech-to-text API endpoints designed to parse and translate audio inputs. These endpoints, namely /v1/audio/transcriptions and /v1/audio/translations, expose an attack surface to authenticated clients.

This vulnerability belongs to the class of CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). The engine fails to restrict raw memory allocations when parsing multipart HTTP file uploads. This behavior permits an attacker to send arbitrarily large payloads that exhaust system resources prior to validation checks.

Successful exploitation results in process termination. Because vLLM hosts computationally heavy models, a sudden resource depletion often causes the operating system's Out-Of-Memory (OOM) killer to terminate the main engine process. This results in a complete denial of service for all users relying on the affected instance.

The core technical defect resides in the execution flow within the speech-to-text API router. When a client uploads an audio file, Starlette (the underlying ASGI framework used by FastAPI) instantiates an UploadFile object. To parse the file contents, the route handler executes the expression audio_data = await request.file.read().

Executing read() without bounded constraints instructs Starlette to ingest the incoming multipart stream entirely. The framework allocates heap memory proportional to the size of the received file payload and stores it as a raw Python bytes object. This allocation occurs immediately upon receipt of the request.

While vLLM defines a configuration parameter named VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (defaulting to 25 MB), this variable was only evaluated after the file was fully materialized in memory. If an attacker uploads a multi-gigabyte file, the server allocates gigabytes of physical RAM. If the allocated amount exceeds available memory, the host kernel triggers a SIGKILL to reclaim memory resources.

The following diagram outlines the sequence of events leading to system-level process termination when an oversized upload is received:

In vulnerable versions, the route handler in vllm/entrypoints/speech_to_text/transcription/api_router.py processed incoming requests directly via standard Starlette file streams:

# Vulnerable Implementation
@router.post("/v1/audio/transcriptions")
async def create_transcriptions(...):
    ...
    # Memory is allocated dynamically for the full file size here
    audio_data = await request.file.read()
    ...

To resolve this flaw, the developers introduced a validation helper named read_upload_with_limit in the file vllm/entrypoints/speech_to_text/base/utils.py and modified the router endpoints to use it:

# Patched Implementation
@router.post("/v1/audio/transcriptions")
async def create_transcriptions(...):
    ...
    # Validation and bounded streaming are applied during ingestion
    audio_data = await read_upload_with_limit(request.file)
    ...

This helper verifies the Content-Length header via file.size. If the metadata reports a size exceeding VLLM_MAX_AUDIO_CLIP_FILESIZE_MB, the server rejects the request immediately. To protect against spoofed or missing headers, the helper processes the stream in incremental chunks of 64 KiB (_READ_CHUNK_SIZE), keeping a running total of ingested bytes. If this total crosses the threshold, the upload is aborted and the stream is discarded. This is a complete fix that prevents uncontrolled heap expansion.

Exploitation requires network reachability to the /v1/audio/transcriptions or /v1/audio/translations endpoints. If the host requires API key authentication, the attacker must possess standard credentials. No specialized tools are required; standard HTTP client libraries can facilitate the attack.

An attacker crafts a multipart form-data payload containing an excessively large file. Because Starlette processes streamed chunked uploads, the attacker can use the Transfer-Encoding: chunked header to stream data without declaring the Content-Length header, bypassing basic frontend gateway checks.

Upon receiving the stream, the backend continuously stores incoming data in heap memory. The allocation continues until the server's free physical memory is exhausted. At this stage, the OS kernel's Out-Of-Memory subsystem triggers and terminates the vllm worker process, resulting in an immediate denial of service.

The impact of this vulnerability is classified as High for availability, but carries zero impact for confidentiality or integrity. Because the engine processes large, complex transformer models, these servers typically run with high baseline memory overhead. Consequently, even small spikes in heap usage can cause process termination.

When the vLLM process is terminated, all ongoing and queued inference tasks across other endpoints (including standard text-generation models) fail immediately. This behavior disrupts operations across any microservices reliant on the affected vLLM instance.

The vulnerability is assigned a CVSS score of 6.5 (Medium). The requirement for a valid API token in authenticated environments serves as the primary barrier preventing automated mass-exploitation, maintaining lower overall exposure risk.

The primary remediation strategy is upgrading the vllm library to version 0.24.0 or later. This version contains the read_upload_with_limit implementation that protects against both buffer exhaustion and chunked upload evasion.

If upgrading immediately is not feasible, administrators can apply mitigation at the network layer. Configure reverse proxies or API gateways (such as Nginx or Envoy) to restrict client payload sizes on these routes. For example, adding client_max_body_size 25M; in Nginx prevents oversized streams from reaching the vLLM backend.

Additionally, administrators can enforce strict containerization constraints. Limiting container memory bounds via cgroups prevents host-wide resource depletion and allows orchestration tools (e.g., Kubernetes) to automatically restart the terminated container, reducing overall downtime.