vLLM speech-to-text routes buffer the whole audio upload before the size check

In brief Most LLM security writing is about prompts. This one is about plumbing. A vulnerability disclosed on July 6, 2026 in vLLM’s audio endpoints shows the server reads an entire uploaded audio file into memory before it checks the configured size limit — so a reachable caller can send an oversized upload and force the process to allocate memory proportional to the file, creating memory pressure or killing the process. It affects vLLM 0.22.0–0.23.x; the fix is in 0.24.0. This is a class-of-bug writeup, not an exploit.

What is this?

vLLM is one of the most widely deployed engines for serving large language models. When it serves a speech model, it exposes OpenAI-compatible audio routes — /v1/audio/transcriptions and /v1/audio/translations — that accept an uploaded audio file as a multipart request.

The disclosed flaw, published to the CVE ecosystem on July 6, 2026 and documented in vLLM’s own GitHub security advisory (GHSA-v82g-2437-67m2), is an ordering mistake in how those routes handle uploads. vLLM ships a documented cap on audio uploads — VLLM_MAX_AUDIO_CLIP_FILESIZE_MB, defaulting to 25 MB — but the size check runs later in the speech-to-text preprocessing step, after the file has already been read into memory. It is rated CVSS 6.5 (medium), with impact limited to availability. There is no code execution and no data leak here; the payoff is denial of service.

How it works

The mechanism is a textbook uncontrolled resource consumption pattern (CWE-400 / CWE-770), and there is nothing exotic to reproduce — the point is the sequence, not a payload.

Request lifecycle on the audio routes (vulnerable versions)
----------------------------------------------------------
1. Client POSTs a multipart audio upload to /v1/audio/transcriptions
2. Handler calls request.file.read()  --> ENTIRE file materialised in RAM
3. Speech-to-text preprocessing runs
4. Only now: compare size against VLLM_MAX_AUDIO_CLIP_FILESIZE_MB
5. Oversized request finally rejected -- but the memory was already spent

Because the full body is buffered at step 2, the memory vLLM allocates scales with the attacker-chosen upload size, not with the 25 MB policy the operator thinks is protecting them. A single oversized multipart upload — or a handful in parallel — inflates resident memory before the request is thrown out. Depending on the deployment’s resource limits, that means degraded latency for legitimate requests, out-of-memory pressure, or an outright process kill. The advisory notes the routes require some level of access to reach, and the flaw is remotely reachable over the network with low attack complexity.

Why it matters

Inference servers are increasingly treated as ordinary web services, but they carry unusually heavy per-request cost: GPUs, large resident models, and media-preprocessing pipelines. That makes them a soft target for resource-exhaustion attacks, where the goal is not to steal anything but to knock a service over cheaply. A size limit that is documented but enforced after the expensive allocation is a common and easy-to-miss failure — the guard exists, it just runs one step too late.

The broader lesson is that untrusted input to an LLM stack has to be bounded before it is materialised, the same discipline any file-upload endpoint needs. The “AI” framing doesn’t change the fundamentals: an audio route is a file-upload route, and file-upload routes that read first and validate second are how you get memory-exhaustion denial of service.

Defenses

1. Upgrade to vLLM 0.24.0 or later. The fix (pull request #45510) moves enforcement so the size limit is applied before the upload is fully buffered. Check your version with pip show vllm.
2. Enforce a request-body-size limit at the edge. Put an authenticated gateway or reverse proxy in front of vLLM and cap upload size there (for example nginx client_max_body_size), so oversized requests are rejected before they ever reach the inference process. This defends the whole class, not just this one route.
3. Don’t expose raw vLLM endpoints to untrusted callers. Default vLLM has weak-to-no authentication; restrict ingress and require auth on the audio routes.
4. Bound the process, not just the policy. Run serving under container/cgroup memory limits with automatic restart, so a memory spike degrades and recovers instead of taking the host down. Add rate limits and per-client quotas on upload endpoints.
5. Validate size before allocation everywhere. Treat “read the whole thing, then check” as an anti-pattern in your own tooling — stream and reject early on any endpoint that accepts untrusted uploads.

Status

Item	Reference	Date	Notes
Vendor advisory	GitHub (GHSA-v82g-2437-67m2) — CVE-2026-55646	2026-07-06	Audio routes buffer full upload before size check
Weakness class	CWE-400 / CWE-770	—	Uncontrolled resource consumption / no allocation limit
Severity	CVSS 3.1 base 6.5 (medium)	—	Network, low complexity; availability-only impact
Affected versions	vLLM	0.22.0 → 0.23.x	Deployments serving speech-to-text models
Patched version	vLLM 0.24.0	2026	Size limit enforced before buffering (PR #45510)

The honest framing is not “another vLLM CVE.” It is that an inference server is a web service with expensive requests, and the oldest rule of untrusted uploads still applies: bound the input before you spend memory on it.