vLLM Audio Endpoint Oversized Upload Burst
vLLM's speech-to-text endpoints read the entire uploaded file into memory before checking whether it's too large. An attacker can exploit this by sending a burst of uploads that are guaranteed to exceed the size limit, forcing the server to allocate memory for each one even though it rejects them, which can degrade or crash the service.
How the attack works
An attacker repeatedly posts audio files to /v1/audio/transcriptions or /v1/audio/translations that are larger than the configured VLLM_MAX_AUDIO_CLIP_FILESIZE_MB limit (25 MB by default). Because the server calls request.file.read() before checking the size, each rejected upload still costs memory proportional to its size. By sending many such oversized files in a short window, or a high volume of near-limit files, the attacker drives up memory consumption without ever getting a successful response. This is a resource-exhaustion technique, not a data breach or code-execution exploit.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 6f1d2c47-9ab0-4e5a-8f21-0c7d3b9e4a18
- Severity
- Medium
Why it matters
An organisation running vLLM could see its inference service degrade or crash under this pattern, causing denial of service for legitimate transcription or translation requests.
What you can do
- →Set VLLM_MAX_AUDIO_CLIP_FILESIZE_MB to a value appropriate for your workload and keep it enforced at a reverse proxy or gateway layer before requests reach vLLM, so oversized bodies are rejected without being read into memory.
- →Add request-size limits and rate limiting per client/IP on the audio endpoints at the load balancer or API gateway.
- →Monitor for repeated 413-style rejections or oversized uploads from the same client in short time windows, and treat sustained bursts as abuse rather than user error.
- →If you run capacity or CI tests that intentionally send oversized clips, tag or source them separately so they can be excluded from abuse monitoring.
Known benign look-alikes
- Legitimate long-form transcription work (podcasts, all-hands recordings, court audio) where the operator has raised VLLM_MAX_AUDIO_CLIP_FILESIZE_MB above the 25 MB default — those clips exceed this rule's oversize threshold while being accepted by the server. Tune MAX_BYTES in the script to the deployed limit.
- A user or SDK retry loop re-posting one large file after a 413, three or more times inside 60 seconds.
- Capacity or load testing of a self-hosted vLLM deployment, and CI regression tests that intentionally probe the file-size limit.
- Batch pipelines that fan out many 16-25 MB clips concurrently to one endpoint and cross the 512 MB in-window aggregate threshold.
- A reverse proxy that rewrites Content-Length or buffers uploads may make the observed size larger than the client's actual clip.