Loading
Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: <= 0.23.0
Patched in 0.24.0
Details
The audio decode-duration guard (max_duration_s, env VLLM_MAX_AUDIO_DECODE_DURATION_S, 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, input_audio 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.load_base64) 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.
The guard rejects long audio during decode (before allocation), implemented in vllm/multimodal/media/audio.py:
load_audio_pyav — metadata reject (~82-98) and live sample-count reject (~129-136)load_audio_soundfile — frames reject (~165-174)All are gated on if max_duration_s is not None.
It is passed in exactly one place — the transcription serving layer:
# .../speech_to_text/base/serving.py:~170-174
load_audio(buf, sr=..., max_duration_s=self.max_audio_decode_duration_s)
# self.max_audio_decode_duration_s = envs.VLLM_MAX_AUDIO_DECODE_DURATION_S (default 600)
The chat path never threads it:
# vllm/multimodal/media/audio.py:237-238
def load_bytes(self, data: bytes) -> tuple[npt.NDArray, float]:
return load_audio(BytesIO(data), sr=None) # no max_duration_s -> every guard above is skipped
Unauthenticated reachability chain (chat):
parse_input_audio (chat_utils.py) -> parse_audio -> connector.fetch_audio -> AudioMediaIO._load_data_url -> load_base64 -> load_bytes -> load_audio(..., sr=None). The connector never passes max_duration_s, and inline data: URLs need no HTTP fetch (so VLLM_AUDIO_FETCH_TIMEOUT does not bound them). The OpenAI-compatible server has no auth by default (auth only when --api-key / VLLM_API_KEY is set).
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.
A fix was introduced in this MR: https://github.com/vllm-project/vllm/pull/45908
EPSS, exploit probability
Low0.73%
estimated chance of real-world exploitation in the next 30 days, higher than 54.3% of every CVE FIRST.org scores
Refreshed 11/1/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.