vLLM: audio decompression bomb via input_audio or audio_url exhausts serving node memory

Impact

The AudioMediaIO multimodal path in vLLM 0.19.0 through 0.23.x calls load_audio without the max_duration_s decoded-duration limit, so a small compressed clip submitted as input_audio or audio_url expands into an enormous decoded PCM buffer. Host memory is exhausted and the serving process dies or is OOM-killed, dropping every concurrent request on that replica and leaving its GPUs idle until restart. The request itself is tiny, so rate limits sized by payload bytes do not catch it.

Who can reach it

An authenticated client of /v1/chat/completions on a vLLM build with audio input enabled. Anyone holding a valid API key for the endpoint is enough.

What to do

Upgrade vLLM to 0.24.0 or later and restart the serving processes. Where upgrading has to wait, disable audio input or enforce a decoded-duration and decompression-ratio cap on audio ahead of vLLM. Serving-process restart only - no node drain or reboot.

References

Related entries

• vLLM: out-of-vocabulary stop_token_ids crash the engine and write past the V2 runner logits bufferCVE-2026-116181 · vLLM (OpenAI-compatible API, stop_token_ids validation)High
• NVIDIA TensorRT-LLM: server-side request forgery lets a local user make the serving process issue arbitrary requestsCVE-2026-24269 · NVIDIA TensorRT-LLM (server-side request forgery in the serving component)High
• vLLM (`MediaConnector`): SSRF, recurrence of CVE-2025-6242CVE-2026-24779 · vLLM (`MediaConnector`)High
• vLLM (`load_from_url_async`): Bypass of the CVE-2026-24779 SSRF fixCVE-2026-25960 · vLLM (`load_from_url_async`)High
• LangSmith SDK: pulling a public Hub prompt deserializes attacker-controlled LangChain objectsCVE-2026-45134 · LangSmith SDK (pull_prompt / pullPrompt manifest deserialization)High
• picklescan: `scan_pytorch` bypass via forged magic numbersCVE-2026-53875 · picklescanHigh