# vLLM Audio Route Oversized Upload Memory Exhaustion

- **Severity:** Medium
- **Signature ID:** `b7c4f0d2-3a19-4e6b-9c58-6f2d1a84e370`

## Summary

vLLM's speech-to-text endpoints read the whole uploaded file into memory before checking if it's too large. An attacker who sends very large or repeated large audio uploads can exhaust server memory and crash the inference process, a denial-of-service that costs nothing but bandwidth.

## How the attack works

An attacker sends a file to /v1/audio/transcriptions or /v1/audio/translations that is at or above the documented 25 MiB size limit. Because vLLM buffers the full upload into memory before enforcing that limit, each oversized request consumes memory regardless of whether it's ultimately rejected. Sending a single very large file is one exploit path; sending a burst of four or more large (8 MiB+) uploads to the same host within two minutes is another, amplifying memory pressure until the process runs out of memory and terminates.

## Why it matters

An attacker can knock a vLLM inference server offline (denial of service) using only oversized or repeated HTTP uploads, no authentication bypass or code execution needed, disrupting transcription/translation service for all users.

## What you can do

- Enforce a request body size limit at the reverse proxy or load balancer, in front of vLLM, so oversized uploads are rejected before reaching the application.
- Set VLLM_MAX_AUDIO_CLIP_FILESIZE_MB to match your actual expected clip sizes and verify it is checked as early as possible in your deployment.
- Rate-limit or throttle repeated large uploads from the same client to the audio endpoints.
- Monitor memory usage and process restarts on the inference server, and alert on repeated large uploads to the same route within short time windows.

## Known benign look-alikes

- Legitimate long-form transcription work — meeting recordings, podcasts or interview audio routinely exceed 25 MiB and will be reported once each. Raise DOC_LIMIT or LARGE in the script to match your deployment's configured VLLM_MAX_AUDIO_CLIP_FILESIZE_MB.
- Batch transcription pipelines that submit a queue of large clips back to back; these trip the burst branch. The report-only action means the batch still runs.
- Client-side retry loops after a 413/timeout, which replay the same large body several times within the two-minute window.
- Capacity or soak testing of a self-hosted vLLM audio endpoint.
- Proxied gateways where Content-Length covers multipart overhead for several small clips in one request, inflating the measured size.

## References

- https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html
- https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
- https://attack.mitre.org/techniques/T1499/003/

---
Source: https://www.netzilo.com/threats/vllm-audio-oversized-upload-dos