CVE-2026-116175: vLLM: audio decompression bomb exhausts server memory
MEDIUMvLLM versions 0.19.0 up to (but not including) 0.24.0 fail to enforce a decoded-duration limit when processing audio sent through the multimodal path, so a small compressed audio file can expand into huge decoded PCM data and exhaust server memory. Any authenticated user, including holders of a low-privilege API key, can trigger an out-of-memory denial of service against the /v1/chat/completions endpoint with a single crafted request. The CVSS score is a moderate 6.5, with availability impact only (no confidentiality or integrity loss), and there is no known public exploit, no Nuclei template, no KEV listing and no EPSS data, so near-term mass exploitation looks unlikely. Shared or multi-tenant inference gateways and any deployment that issues API keys to external parties or customers carry the highest exposure, since one request could take down GPU serving capacity for everyone. Upgrade to vLLM 0.24.0 or later, and until then restrict audio inputs or enforce request size and rate limits at the gateway.
What is the risk?
Medium overall. Exploitation is low complexity, network-reachable and needs only low privileges with no user interaction, but impact is limited to availability. Likelihood is tempered by the authentication requirement and the absence of public exploits, Nuclei templates, KEV listing or EPSS signal (all N/A or No). Risk rises sharply for multi-tenant or internet-exposed inference endpoints where API keys are broadly distributed, because a single process crash can interrupt serving for all tenants and may need manual recovery. Confidence: HIGH on the vulnerability mechanics (vendor advisory and VulnCheck), LOW on real-world exploitation likelihood due to missing data.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade vLLM to 0.24.0 or later, which applies the max_duration_s decoded-duration limit in the AudioMediaIO path. 2) If you cannot patch immediately, block or strip input_audio and audio_url content at an API gateway or reverse proxy, or disable audio modalities for models that do not need them. 3) Enforce per-key rate limits, request body size caps and audio payload size caps, and restrict which clients get API keys. 4) Set container and process memory limits and use automatic restart with health checks so an OOM event does not become a prolonged outage. 5) Where audio_url is allowed, restrict fetchable domains and limit download size. 6) Detection: alert on sudden memory spikes in vLLM workers, OOM-kill events, and repeated /v1/chat/completions requests carrying audio content from a single key, then review the GHSA-r45p-7qwx-qwjw advisory for the full fix details.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-116175?
vLLM versions 0.19.0 up to (but not including) 0.24.0 fail to enforce a decoded-duration limit when processing audio sent through the multimodal path, so a small compressed audio file can expand into huge decoded PCM data and exhaust server memory. Any authenticated user, including holders of a low-privilege API key, can trigger an out-of-memory denial of service against the /v1/chat/completions endpoint with a single crafted request. The CVSS score is a moderate 6.5, with availability impact only (no confidentiality or integrity loss), and there is no known public exploit, no Nuclei template, no KEV listing and no EPSS data, so near-term mass exploitation looks unlikely. Shared or multi-tenant inference gateways and any deployment that issues API keys to external parties or customers carry the highest exposure, since one request could take down GPU serving capacity for everyone. Upgrade to vLLM 0.24.0 or later, and until then restrict audio inputs or enforce request size and rate limits at the gateway.
Is CVE-2026-116175 actively exploited?
No confirmed active exploitation of CVE-2026-116175 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-116175?
1) Upgrade vLLM to 0.24.0 or later, which applies the max_duration_s decoded-duration limit in the AudioMediaIO path. 2) If you cannot patch immediately, block or strip input_audio and audio_url content at an API gateway or reverse proxy, or disable audio modalities for models that do not need them. 3) Enforce per-key rate limits, request body size caps and audio payload size caps, and restrict which clients get API keys. 4) Set container and process memory limits and use automatic restart with health checks so an OOM event does not become a prolonged outage. 5) Where audio_url is allowed, restrict fetchable domains and limit download size. 6) Detection: alert on sudden memory spikes in vLLM workers, OOM-kill events, and repeated /v1/chat/completions requests carrying audio content from a single key, then review the GHSA-r45p-7qwx-qwjw advisory for the full fix details.
What systems are affected by CVE-2026-116175?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference APIs, multimodal pipelines, voice-enabled assistants, multi-tenant LLM gateways.
What is the CVSS score for CVE-2026-116175?
CVE-2026-116175 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.31%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0034.001Resource-Intensive QueriesAML.T0040AI Model Inference API AccessCompliance Controls Affected
What are the technical details?
Original Advisory
vLLM from 0.19.0 before 0.24.0 contains a decompression bomb vulnerability because the AudioMediaIO multimodal path calls load_audio without the max_duration_s decoded-duration limit. Authenticated attackers can send small compressed audio via input_audio or audio_url in /v1/chat/completions requests that expands to huge decoded PCM, exhausting server memory.
Exploitation Scenario
An attacker with a legitimate low-privilege API key, or a free-tier account on a service that fronts vLLM, crafts a highly compressible audio file, such as very long silence or a tiny file that decodes to hours of PCM audio. They submit it via input_audio (base64) or audio_url in a /v1/chat/completions request. The server decodes the entire clip without a duration cap and consumes all available memory, and the process crashes or is OOM-killed. The attacker repeats the request after each restart to keep the inference service unavailable, disrupting every tenant and any agents or applications that depend on the endpoint.
Weaknesses (CWE)
CWE-409Improper Handling of Highly Compressed Data (Data Amplification)PrimaryCWE-409Improper Handling of Highly Compressed Data (Data Amplification)CWE-409 — Improper Handling of Highly Compressed Data (Data Amplification): The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm