CVE-2026-57173: vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions
vLLM is an inference and serving engine for large language models. Prior to 0.24.0, the inputaudio handling path for /v1/chat/completions calls AudioMediaIO.loadbytes or AudioMediaIO.loadfile without passing VLLMMAXAUDIODECODEDURATIONS to the shared audio decoder. An unauthenticated client can therefore submit a small compressed audio input that expands into a very large float32 PCM allocation, bypassing the duration guard already used by /v1/audio/transcriptions and causing an out-of-memory worker crash. Inline data URLs reach this path without being bounded by VLLMAUDIOFETCHTIMEOUT. The issue affects deployments serving an audio-capable model, and authentication changes only the deployment-specific reachability. This issue is fixed in version 0.24.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
vLLMto a version that resolves this vulnerability.Fixed in 0.24.0
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments running vLLM before 0.24.0 that serve an audio-capable model are affected. The vulnerable endpoint is /v1/chat/completions; whether an attacker can reach it without credentials depends on the deployment's authentication configuration.
What does an attacker need to do to trigger the denial of service?
An attacker needs to submit a crafted, small compressed audio input to /v1/chat/completions. The audio can decompress into a very large float32 PCM allocation and crash a worker through out-of-memory exhaustion; inline data URLs can reach the path without the VLLM_AUDIO_FETCH_TIMEOUT bound.
Is the audio duration guard effective for this endpoint?
No. Before 0.24.0, the /v1/chat/completions input_audio path does not pass VLLM_MAX_AUDIO_DECODE_DURATION_S to the shared decoder, unlike /v1/audio/transcriptions.
What is the available fix?
Upgrade vLLM to version 0.24.0, which fixes the issue.