CVE-2026-57173: vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions
Summary The audio decode-duration guard (maxdurations, env VLLMMAXAUDIODECODEDURATIONS, default 600s) that protects against audio decompression-bomb DoS is wired into only the speech-to-text path (/v1/audio/transcriptions). The chat audio path (/v1/chat/completions, inputaudio content parts) calls the same decoder with no limit, so an unauthenticated client can submit a few-KB compressed audio file that expands to multiple GB of float32 PCM at decode time, OOM-killing the worker. This is a distinct sibling of CVE-2026-5497 (video frame-count bomb, VideoMediaIO.loadbase64) and GHSA-pq5c-rjhq-qp7p (image) in the same media subsystem.
Verified against main at HEAD d78650c (2026-06-16); applicable to the latest release v0.23.0.
Details The guard rejects long audio during decode (before allocation), implemented in vllm/multimodal/media/audio.py: - loadaudiopyav — metadata reject (~82-98) and live sample-count reject (~129-136) - loadaudiosoundfile — frames reject (~165-174)
All are gated on if maxdurations is not None.
It is passed in exactly one place — the transcription serving layer: python .../speechtotext/base/serving.py:~170-174 loadaudio(buf, sr=..., maxdurations=self.maxaudiodecodedurations) self.maxaudiodecodedurations = envs.VLLMMAXAUDIODECODEDURATIONS (default 600)
The chat path never threads it: python vllm/multimodal/media/audio.py:237-238 def loadbytes(self, data: bytes) -> tuple[npt.NDArray, float]: return loadaudio(BytesIO(data), sr=None) # no maxdurations -> every guard above is skipped
Unauthenticated reachability chain (chat): parseinputaudio (chatutils.py) -> parseaudio -> connector.fetchaudio -> AudioMediaIO.loaddataurl -> loadbase64 -> loadbytes -> loadaudio(..., sr=None). The connector never passes maxdurations, and inline data: URLs need no HTTP fetch (so VLLMAUDIOFETCHTIMEOUT does not bound them). The OpenAI-compatible server has no auth by default (auth only when --api-key / VLLMAPIKEY is set).
Impact Unauthenticated remote denial of service (availability) via memory amplification on a default-no-auth endpoint, on any deployment serving an audio-capable model. Same class and impact as the sibling CVE-2026-5497 (video). CWE-770 / CWE-409.
Fix A fix was introduced in this MR: https://github.com/vllm-project/vllm/pull/45908
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/vllmto a version that resolves this vulnerability.Fixed in 0.24.0 - 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.