CVE-2026-116175 in vLLM
Summary
by MITRE • 10/25/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified within vLLM versions ranging from 0.19.0 up to but not including 0.24.0 represents a critical resource exhaustion flaw rooted in the handling of multimodal audio inputs. This specific weakness is classified as CWE-787: Out-of-bounds Read and CWE-400: Uncontrolled Resource Consumption, commonly known as a decompression bomb or zip bomb attack vector. The core technical failure lies within the AudioMediaIO component, which processes multimedia data for large language model inference. When an authenticated user submits audio content through the /v1/chat/completions endpoint via either the input_audio field or the audio_url parameter, the system invokes the load_audio function to decode the media file into a raw Pulse Code Modulation PCM format suitable for processing by the underlying neural network models.
The fundamental flaw is that this decoding process lacks an enforcement of the max_duration_s limit, which is designed to cap the duration of decoded audio data. Without this constraint, attackers can craft maliciously small compressed audio files that expand into massive amounts of uncompressed PCM data when decompressed. This technique exploits the high compression ratio achievable with certain codecs or specially crafted archives, allowing a few kilobytes of input to generate gigabytes of output in memory. Because vLLM operates as an inference server handling concurrent requests, this unbounded expansion directly impacts the host system's available random access memory.
The operational impact of this vulnerability is severe for service availability and integrity. An authenticated attacker can trigger repeated or sustained decompression bombs that rapidly consume all available heap space on the server hosting the vLLM instance. This leads to out-of-memory conditions, causing the application process to crash or be terminated by the operating system's memory manager. In a production environment serving multiple users, this results in a Denial of Service for legitimate traffic, effectively taking down the AI inference service until the affected pods or processes are restarted and cleared of their exhausted state. The attack requires authentication, which limits its scope compared to unauthenticated exploits but remains significant given that many deployments restrict access only by network perimeter rather than strict identity verification at every API call level.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1496: Resource Hijacking, specifically the sub-technique of resource exhaustion to disrupt service availability. It also reflects CWE-787 where improper memory access leads to system instability. The lack of input validation regarding decoded size is a common oversight in systems that prioritize ease of integration over strict boundary checking for multimedia payloads.
Mitigation strategies must focus on enforcing strict limits at the decoding stage rather than relying solely on file size checks, which can be bypassed by high-compression techniques. Upgrading to vLLM version 0.24.0 or later is the primary remediation step as it addresses this specific gap in the AudioMediaIO logic. For environments where immediate upgrading is not feasible, administrators should implement network-level rate limiting and request size caps on the /v1/chat/completions endpoint to restrict the volume of data processed per session. Additionally, deploying a reverse proxy or API gateway with deep packet inspection capabilities can help detect anomalous audio payloads before they reach the vLLM application layer. It is also advisable to configure container resource limits such as memory quotas in Kubernetes environments to prevent any single process from exhausting host-level resources, thereby containing the blast radius of potential exploitation attempts.