GHSA-hcwq-8wjf-3gcr: Medium severity pip/vllm vulnerability
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
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
vllm-project/vllmto a version that resolves this vulnerability.Patch CVE-2026-5497 - Configuration
Ensure the chat audio input path (input_audio content parts) threads the decode-duration limit so audio decoding uses max_duration_s=self.max_audio_decode_duration_s (env VLLM_MAX_AUDIO_DECODE_DURATION_S), instead of calling load_audio(BytesIO(data), sr=None) without max_duration_s.
vLLM (OpenAI-compatible server chat audio path: /v1/chat/completions) max_audio_decode_duration_s (env: VLLM_MAX_AUDIO_DECODE_DURATION_S) = 600 - Compensating control
Enable API authentication for the OpenAI-compatible server by setting --api-key / VLLM_API_KEY, since the endpoint has no auth by default.
Event History
Frequently Asked Questions
Which API endpoint is exposed to this denial-of-service issue?
The affected path is /v1/chat/completions when requests include input_audio content parts. The decode-duration limit is applied to /v1/audio/transcriptions but is not passed to the chat audio path.
Does the default audio decode-duration setting protect chat audio requests?
No. Although max_duration_s defaults to 600 seconds and can be set with VLLM_MAX_AUDIO_DECODE_DURATION_S, the chat audio path calls the decoder without this limit. The setting protects the transcription path only.
What does an attacker need to trigger the issue?
An unauthenticated client can submit a small compressed audio file through the chat audio interface. The file can expand into multiple gigabytes of float32 PCM during decoding and OOM-kill the worker.
Which versions are confirmed affected?
The issue was verified against main at commit d78650c on 2026-06-16 and is stated to apply to the latest release, v0.23.0.