{"id":"CVE-2026-57173","aliases":["EUVD-2026-80880","GHSA-hcwq-8wjf-3gcr","PYSEC-2026-4179"],"status":"published","title":"vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions","description":"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.","severity":{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.0073,"percentile":0.54726,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-770"],"published":"2026-09-16T16:34:39Z","modified":"2026-11-04T02:47:43Z","fixes":[{"ecosystem":"PyPI","package":"vllm","fixed_in":["0.24.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"vllm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.23.0"},{"fixed":"0.24.0"}]}]},{"source":"osv","ecosystem":"PyPI","package":"vllm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.24.0"}]}],"versions":["0.0.1","0.1.0","0.1.1","0.1.2","0.1.3","0.1.4","0.1.5","0.1.6","0.1.7","0.10.0","0.10.1","0.10.1.1","0.10.2","0.11.0","0.11.1","0.11.2","0.12.0","0.13.0","0.14.0","0.14.1","0.15.0","0.15.1","0.16.0","0.17.0","0.17.1","0.18.0","0.18.1","0.19.0","0.19.1","0.2.0","0.2.1","0.2.1.post1","0.2.2","0.2.3","0.2.4","0.2.5","0.2.6","0.2.7","0.20.0","0.20.1","0.20.2","0.21.0","0.22.0","0.22.1","0.23.0","0.3.0","0.3.1","0.3.2","0.3.3","0.4.0","0.4.0.post1","0.4.1","0.4.2","0.4.3","0.5.0","0.5.0.post1","0.5.1","0.5.2","0.5.3","0.5.3.post1","0.5.4","0.5.5","0.6.0","0.6.1","0.6.1.post1","0.6.1.post2","0.6.2","0.6.3","0.6.3.post1","0.6.4","0.6.4.post1","0.6.5","0.6.6","0.6.6.post1","0.7.0","0.7.1","0.7.2","0.7.3","0.8.0","0.8.1","0.8.2","0.8.3","0.8.4","0.8.5","0.8.5.post1","0.9.0","0.9.0.1","0.9.1","0.9.2"]},{"source":"osv","ecosystem":"PyPI","package":"vllm","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.24.0"}]}],"versions":["0.0.1","0.1.0","0.1.1","0.1.2","0.1.3","0.1.4","0.1.5","0.1.6","0.1.7","0.10.0","0.10.1","0.10.1.1","0.10.2","0.11.0","0.11.1","0.11.2","0.12.0","0.13.0","0.14.0","0.14.1","0.15.0","0.15.1","0.16.0","0.17.0","0.17.1","0.18.0","0.18.1","0.19.0","0.19.1","0.2.0","0.2.1","0.2.1.post1","0.2.2","0.2.3","0.2.4","0.2.5","0.2.6","0.2.7","0.20.0","0.20.1","0.20.2","0.21.0","0.22.0","0.22.1","0.23.0","0.3.0","0.3.1","0.3.2","0.3.3","0.4.0","0.4.0.post1","0.4.1","0.4.2","0.4.3","0.5.0","0.5.0.post1","0.5.1","0.5.2","0.5.3","0.5.3.post1","0.5.4","0.5.5","0.6.0","0.6.1","0.6.1.post1","0.6.1.post2","0.6.2","0.6.3","0.6.3.post1","0.6.4","0.6.4.post1","0.6.5","0.6.6","0.6.6.post1","0.7.0","0.7.1","0.7.2","0.7.3","0.8.0","0.8.1","0.8.2","0.8.3","0.8.4","0.8.5","0.8.5.post1","0.9.0","0.9.0.1","0.9.1","0.9.2"]}],"products":[{"vendor":"vllm","product":"vllm"},{"vendor":"vllm-project","product":"vllm"}],"references":[{"url":"https://github.com/vllm-project/vllm/security/advisories/GHSA-hcwq-8wjf-3gcr","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web"]},{"url":"https://github.com/vllm-project/vllm/pull/45908","tags":["x_refsource_MISC","Issue Tracking","Patch","fix","web"]},{"url":"https://github.com/vllm-project/vllm/commit/3d20275bb4d434f53055c3c0b645fd8bb072965e","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/vllm-project/vllm/releases/tag/v0.24.0","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-57173","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-hcwq-8wjf-3gcr","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/57xxx/CVE-2026-57173.json","tags":["advisory"]},{"url":"https://github.com/vllm-project/vllm","tags":["package"]},{"url":"https://pypi.org/project/vllm","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-57173","title":"vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions","description":"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.","status":"published","published":"2026-09-16T16:34:39.144Z","modified":"2026-09-18T18:11:54.721Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T13:43:56.024247Z"}],"euvd":[{"id":"EUVD-2026-80880","description":"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.","status":"published","published":"2026-09-16T16:34:39Z","modified":"2026-09-18T18:11:54Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T17:28:07.943492Z"}],"ghsa":[{"id":"GHSA-hcwq-8wjf-3gcr","title":"vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions","description":"### Summary\nThe 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.\n\nVerified against `main` at HEAD `d78650c` (2026-06-16); applicable to the latest release v0.23.0.\n\n### Details\nThe guard rejects long audio *during* decode (before allocation), implemented in `vllm/multimodal/media/audio.py`:\n- `load_audio_pyav` — metadata reject (~82-98) and live sample-count reject (~129-136)\n- `load_audio_soundfile` — frames reject (~165-174)\n\nAll are gated on `if max_duration_s is not None`.\n\nIt is passed in exactly **one** place — the transcription serving layer:\n```python\n# .../speech_to_text/base/serving.py:~170-174\nload_audio(buf, sr=..., max_duration_s=self.max_audio_decode_duration_s)\n#   self.max_audio_decode_duration_s = envs.VLLM_MAX_AUDIO_DECODE_DURATION_S  (default 600)\n```\n\nThe chat path never threads it:\n```python\n# vllm/multimodal/media/audio.py:237-238\ndef load_bytes(self, data: bytes) -\u003e tuple[npt.NDArray, float]:\n    return load_audio(BytesIO(data), sr=None)   # no max_duration_s -\u003e every guard above is skipped\n```\n\nUnauthenticated reachability chain (chat):\n`parse_input_audio` (`chat_utils.py`) -\u003e `parse_audio` -\u003e `connector.fetch_audio` -\u003e `AudioMediaIO._load_data_url` -\u003e `load_base64` -\u003e `load_bytes` -\u003e `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).\n\n### Impact\nUnauthenticated 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.\n\n### Fix\nA fix was introduced in this MR: https://github.com/vllm-project/vllm/pull/45908","status":"published","published":"2026-09-16T22:12:17Z","modified":"2026-09-16T22:12:18Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:41:17.136201Z"}],"nvd":[{"id":"CVE-2026-57173","description":"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.","status":"published","published":"2026-09-16T17:17:24.603Z","modified":"2026-10-07T14:24:22.1Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"secondary"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T14:12:48.630594Z"}],"osv":[{"id":"CVE-2026-57173","title":"vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions","description":"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.","status":"published","published":"2026-09-16T16:34:39.144Z","modified":"2026-11-10T02:45:36.028110535Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-770"],"updated_at":"2026-11-10T03:16:41.950556Z"},{"id":"GHSA-hcwq-8wjf-3gcr","title":"vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions","description":"### Summary\nThe 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.\n\nVerified against `main` at HEAD `d78650c` (2026-06-16); applicable to the latest release v0.23.0.\n\n### Details\nThe guard rejects long audio *during* decode (before allocation), implemented in `vllm/multimodal/media/audio.py`:\n- `load_audio_pyav` — metadata reject (~82-98) and live sample-count reject (~129-136)\n- `load_audio_soundfile` — frames reject (~165-174)\n\nAll are gated on `if max_duration_s is not None`.\n\nIt is passed in exactly **one** place — the transcription serving layer:\n```python\n# .../speech_to_text/base/serving.py:~170-174\nload_audio(buf, sr=..., max_duration_s=self.max_audio_decode_duration_s)\n#   self.max_audio_decode_duration_s = envs.VLLM_MAX_AUDIO_DECODE_DURATION_S  (default 600)\n```\n\nThe chat path never threads it:\n```python\n# vllm/multimodal/media/audio.py:237-238\ndef load_bytes(self, data: bytes) -\u003e tuple[npt.NDArray, float]:\n    return load_audio(BytesIO(data), sr=None)   # no max_duration_s -\u003e every guard above is skipped\n```\n\nUnauthenticated reachability chain (chat):\n`parse_input_audio` (`chat_utils.py`) -\u003e `parse_audio` -\u003e `connector.fetch_audio` -\u003e `AudioMediaIO._load_data_url` -\u003e `load_base64` -\u003e `load_bytes` -\u003e `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).\n\n### Impact\nUnauthenticated 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.\n\n### Fix\nA fix was introduced in this MR: https://github.com/vllm-project/vllm/pull/45908","status":"published","published":"2026-09-16T22:12:17Z","modified":"2026-10-01T17:56:17.490546142Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-770"],"updated_at":"2026-11-02T15:46:48.920784Z"},{"id":"PYSEC-2026-4179","title":"vLLM: Unauthenticated audio decompression-bomb DoS in /v1/chat/completions","description":"### Summary\nThe 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.\n\nVerified against `main` at HEAD `d78650c` (2026-06-16); applicable to the latest release v0.23.0.\n\n### Details\nThe guard rejects long audio *during* decode (before allocation), implemented in `vllm/multimodal/media/audio.py`:\n- `load_audio_pyav` — metadata reject (~82-98) and live sample-count reject (~129-136)\n- `load_audio_soundfile` — frames reject (~165-174)\n\nAll are gated on `if max_duration_s is not None`.\n\nIt is passed in exactly **one** place — the transcription serving layer:\n```python\n# .../speech_to_text/base/serving.py:~170-174\nload_audio(buf, sr=..., max_duration_s=self.max_audio_decode_duration_s)\n#   self.max_audio_decode_duration_s = envs.VLLM_MAX_AUDIO_DECODE_DURATION_S  (default 600)\n```\n\nThe chat path never threads it:\n```python\n# vllm/multimodal/media/audio.py:237-238\ndef load_bytes(self, data: bytes) -\u003e tuple[npt.NDArray, float]:\n    return load_audio(BytesIO(data), sr=None)   # no max_duration_s -\u003e every guard above is skipped\n```\n\nUnauthenticated reachability chain (chat):\n`parse_input_audio` (`chat_utils.py`) -\u003e `parse_audio` -\u003e `connector.fetch_audio` -\u003e `AudioMediaIO._load_data_url` -\u003e `load_base64` -\u003e `load_bytes` -\u003e `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).\n\n### Impact\nUnauthenticated 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.\n\n### Fix\nA fix was introduced in this MR: https://github.com/vllm-project/vllm/pull/45908","status":"published","published":"2026-10-01T16:38:32.289483Z","modified":"2026-10-01T17:45:09.322181474Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:52:57.671918Z"}]}}