CVE-2026-57173
mediumpriority · track · 0EPSS 0.007 · 54 %ileDEUSEPSS · scored 2026-10-27
vLLM is an inference and serving engine for large language models. Prior to 0.24.0, the input_audio handling path for /v1/chat/completions calls AudioMediaIO.load_bytes or AudioMediaIO.load_file without passing VLLM_MAX_AUDIO_DECODE_DURATION_S 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 VLLM_AUDIO_FETCH_TIMEOUT. 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.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (4)
Products and version ranges known to be affected.
advisories (3)
Vendor and ecosystem advisories describing this.
- WID-SEC-W-2026-2975vllm: Schwachstelle ermöglicht Denial of ServiceDeutsch2026-08-23csaf · cert_bundDE
Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in vllm ausnutzen, um einen Denial of Service Angriff durchzuführen.
- GHSA-hcwq-8wjf-3gcrvLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions2026-09-16ghsa · osvUS
### Summary 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. ### Details 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: ```python # .../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: ```python # 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). ### 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
- PYSEC-2026-4179vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions2026-10-01vendor · osvUS
### Summary 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. ### Details 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: ```python # .../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: ```python # 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). ### 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
also known as (2)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (4) nvd
External citations — patches, advisories, analysis.
- https://github.com/vllm-project/vllm/commit/3d20275bb4d434f53055c3c0b645fd8bb072965ePatch
- https://github.com/vllm-project/vllm/pull/45908Issue TrackingPatch
- https://github.com/vllm-project/vllm/releases/tag/v0.24.0Release Notes
- https://github.com/vllm-project/vllm/security/advisories/GHSA-hcwq-8wjf-3gcrVendor Advisory
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan