CVE-2026-55646: vLLM: Speech-to-text upload size limit is enforced after full UploadFile read

VLLM_MAX_AUDIO_CLIP_FILESIZE_MB is documented as the largest audio file the speech-to-text API accepts, with a default of 25 MB. But the /v1/audio/transcriptions and /v1/audio/translations routes call await request.file.read() with no size argument. That copies the whole upload into a bytes object. The size check in _preprocess_speech_to_text() runs afterward, on the object already in memory.

So the limit rejects the request, but only after the memory is allocated. A caller can upload a file far above 25 MB and force vLLM to hold all of it. With several parallel uploads, or a tight container memory limit, the process can be killed before it rejects anything. That takes the inference server down for everyone.

The preconditions are: the deployment exposes one of the two audio routes, a speech-to-text model is configured, and the caller can submit requests, including with any API key the deployment requires. The CVSS vector has low privileges and rates availability only. The reporter states there is no code execution or data exposure. A body-size limit at a reverse proxy or the ASGI layer stops the request before vLLM sees it.

The pip package vllm from 0.22.0 up to, but not including, 0.24.0. The reporter validated current head at the time, and did not find the commit that introduced the issue. Servers are exposed only when they serve a speech-to-text model and expose /v1/audio/transcriptions or /v1/audio/translations.

pip show vllm

Check whether VLLM_MAX_AUDIO_CLIP_FILESIZE_MB is set. It does not protect memory in affected versions either way.

Upgrade to vLLM 0.24.0:

pip install --upgrade "vllm>=0.24.0"

The fix, pull request 45510, reads the upload in bounded chunks and rejects it once it passes the limit, so the full file is never loaded. The pull request page names vllm/entrypoints/speech_to_text/base/utils.py as the place the logic lives.

The advisory notes one mitigation for older versions: set a request body-size limit at the reverse proxy or ASGI layer, so oversized uploads never reach vLLM. Set it at or just above the audio limit.

Look for the vLLM process or container being killed for memory (OOM kills in the kernel log or container events), or memory spikes that match POSTs to /v1/audio/transcriptions or /v1/audio/translations. In the proxy access logs, find those requests with large Content-Length values, well above 25 MB, especially from one key or address.

Requests that vLLM rejects as too large still cost memory before the rejection, so a stream of rejections with a large body size is a sign of probing. Rate-limit or block the key.

Summary

Current-head vLLM documents VLLM_MAX_AUDIO_CLIP_FILESIZE_MB as the maximum audio file size accepted by the speech-to-text APIs. The default is 25 MB. vllm/envs.py also describes files larger than this value as rejected.

The /v1/audio/transcriptions and /v1/audio/translations routes call await request.file.read() before vLLM checks that limit. In FastAPI and Starlette, UploadFile.read() returns bytes from the uploaded file object; when called without a size argument, the route materializes the remaining file contents. vLLM then performs the compressed file-size check later in _preprocess_speech_to_text() against the already-created bytes object.

As a result, the documented compressed audio file-size limit does not bound the memory allocated by vLLM endpoint code before validation. An oversized multipart upload can cause vLLM to allocate memory proportional to the uploaded file size before rejecting the request as too large.

This is distinct from GHSA-6pr9-rp53-2pmc, which covered decoded PCM expansion after compressed input was accepted. This report covers compressed upload materialization before compressed-size validation.

Technical Details

The upload routes perform an unbounded read before vLLM checks the documented compressed audio file-size limit:

• vllm/entrypoints/speech_to_text/transcription/api_router.py: audio_data = await request.file.read()
• vllm/entrypoints/speech_to_text/translation/api_router.py: audio_data = await request.file.read()
• vllm/entrypoints/speech_to_text/base/serving.py later checks: if len(audio_data) / 1024**2 > self.max_audio_filesize_mb

There is no route-level check of request.file.size, Content-Length, a bounded read(max_bytes + 1), or a streaming copy that stops at the configured limit before the full file is materialized.

This does not appear to be intended behavior. vLLM's security guide treats request-controlled resource use as a security boundary: for example, requests that exceed VLLM_MAX_N_SEQUENCES are rejected before reaching the engine. The speech-to-text upload limit is documented in the same spirit as an API enforced limit, but the first vLLM check happens after the over-limit upload has already been copied into a bytes object.

Impact

Attack requirements:

• the deployment exposes /v1/audio/transcriptions or /v1/audio/translations;
• a speech-to-text capable model/task is configured; and
• the caller can submit requests to the endpoint, including any API key the deployment requires.

An API caller who meets those requirements can send an oversized audio file. vLLM reads the full uploaded file into memory before applying the configured compressed audio file-size limit. This can create memory pressure or, depending on process/container limits and concurrency, terminate the process before the request is rejected.

Suggested severity: Moderate, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (6.5), CWE-770/CWE-400.

The impact is availability-only. This is not a claim of code execution, data access, cross-tenant data exposure, parser-level multipart memory exhaustion, or persistence after process restart. Deployment body-size limits at a reverse proxy or ASGI layer can mitigate the issue before vLLM sees the request, but vLLM's own documented file-size limit does not currently provide that memory boundary.

Suggested Fix

Enforce the compressed audio upload limit before the unbounded read:

• Check reliable upload size metadata before reading when available.
• Read at most max_bytes + 1 bytes in chunks as a defense-in-depth guard against missing or unreliable metadata.
• Share the helper between transcription and translation routes.
• Add regression tests that prove an over-limit UploadFile is rejected without calling an unbounded read().

The important property is that over-limit compressed uploads are rejected before vLLM allocates the full uploaded file as bytes.

Resources

• vLLM security policy: https://github.com/vllm-project/vllm/security/policy
• vLLM speech-to-text docs: https://docs.vllm.ai/en/latest/serving/online_serving/speech_to_text/
• vLLM security guide, request parameter resource limits: https://docs.vllm.ai/en/latest/usage/security/
• vLLM vulnerability management docs: https://docs.vllm.ai/en/latest/contributing/vulnerability_management/
• FastAPI file uploads: https://fastapi.tiangolo.com/reference/uploadfile/
• Starlette uploaded files: https://www.starlette.io/requests/
• Adjacent published audio advisory: https://github.com/vllm-project/vllm/security/advisories/GHSA-6pr9-rp53-2pmc
• Request-parameter resource DoS precedent: https://github.com/vllm-project/vllm/security/advisories/GHSA-3mwp-wvh9-7528

Appendix: Affected Version

Validated against current head:

• commit: 1033ffac2eccf986fdd880f4dee64ca3b22c63c9
• described version: v0.22.1rc0-491-g1033ffac2e

Known affected range: current head. It has not been determined the introducing commit or release range.

Appendix: Proof Of Vulnerability

The attached proof is a non-destructive static probe. It does not upload a large file or contact a running vLLM server:

python3 attached-evidence/poc/audio_upload_size_precheck_probe.py

Observed result:

{
  "pov": "this report",
  "validated": true,
  "default_limit_mb": 25,
  "documented_api_limit": true,
  "routes": {
    "transcription_route": {
      "unbounded_upload_read": true,
      "early_size_guard_before_read": false,
      "chunked_bounded_read": false
    },
    "translation_route": {
      "unbounded_upload_read": true,
      "early_size_guard_before_read": false,
      "chunked_bounded_read": false
    }
  },
  "late_size_check": {
    "present": true
  }
}

Expected behavior: vLLM rejects over-limit audio files before materializing the entire upload into memory in vLLM endpoint code.

Actual behavior: the route materializes the upload into memory first, and only then does vLLM reject the request as exceeding VLLM_MAX_AUDIO_CLIP_FILESIZE_MB.