CVE-2026-57173: Unauthenticated Audio Decompression-Bomb Denial of Service in vLLM

vLLM is an open-source, high-throughput inference and serving engine designed for Large Language Models (LLMs). To support multimodal inputs such as speech-to-text and vision-language tasks, vLLM incorporates media processing pipelines to parse, decode, and transform incoming binary files (such as images and audio) into structured numerical tensors.

Prior to version 0.24.0, a security boundary omission existed within vLLM's audio ingestion pipeline. Specifically, the multimodal chat completions path (/v1/chat/completions) failed to propagate the maximum audio decode duration constraint (VLLM_MAX_AUDIO_DECODE_DURATION_S) when calling underlying audio decoding interfaces. This omission allows unauthenticated attackers to submit crafted audio files that bypass runtime limits.

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). It permits a remote attacker to execute an Endpoint Denial of Service (DoS) attack, commonly referred to as an audio decompression bomb. The impact of this exploit is the immediate exhaustion of physical or virtual memory, resulting in an Out-Of-Memory (OOM) crash of the Python worker processes.

The root cause of this vulnerability lies in the structural separation of API pathways in the vLLM server. The dedicated speech-to-text transcription endpoint (/v1/audio/transcriptions) explicitly enforced duration boundaries. However, the multimodal chat completions endpoint (/v1/chat/completions) relied on the AudioMediaIO class in vllm/multimodal/media/audio.py to ingest and decode audio streams.

Within AudioMediaIO, the helper methods load_bytes and load_file are responsible for deserializing payloads. In vulnerable versions, these methods invoked the shared decoding routine load_audio(data, sr=None) without supplying the keyword argument max_duration_s. Consequently, the parameter defaulted to None inside the underlying backend wrapper, which leverages PyAV or SoundFile decoders.

Without an explicit duration limitation, the decoder attempts to decompress the entire stream regardless of its actual or declared playback length. An attacker can construct a highly compressed audio stream that expands into a massive uncompressed array of 32-bit floating-point (float32) Pulse Code Modulation (PCM) samples in RAM. Because the decompression process occurs synchronously during request parsing, the operating system's Out-Of-Memory (OOM) killer terminates the parent Python process to prevent system-wide instability.

To understand the technical correction, we must review the git diff in the affected module vllm/multimodal/media/audio.py. The patch explicitly introduces global configuration imports and passes the runtime boundary down the execution stack.

# Vulnerable Implementation
class AudioMediaIO:
    # ...
    def load_bytes(self, data: bytes) -> tuple[npt.NDArray, float]:
        # Decodes raw bytes with no max_duration_s parameter supplied
        return load_audio(BytesIO(data), sr=None)
 
    def load_file(self, filepath: Path) -> tuple[npt.NDArray, float]:
        # Decodes target local file with no max_duration_s parameter supplied
        return load_audio(filepath, sr=None)

# Patched Implementation
import vllm.envs as envs
 
class AudioMediaIO:
    # ...
    def load_bytes(self, data: bytes) -> tuple[npt.NDArray, float]:
        # Explicitly propagates the global environmental decode limit
        return load_audio(
            BytesIO(data),
            sr=None,
            max_duration_s=envs.VLLM_MAX_AUDIO_DECODE_DURATION_S,
        )
 
    def load_file(self, filepath: Path) -> tuple[npt.NDArray, float]:
        # Explicitly propagates the global environmental decode limit
        return load_audio(
            filepath,
            sr=None,
            max_duration_s=envs.VLLM_MAX_AUDIO_DECODE_DURATION_S,
        )

The fix is robust against normal payload abuse because the underlying load_audio implementation uses the propagated max_duration_s value to check the container's duration headers or terminate early during streaming decoding. However, a potential weakness remains if the container metadata is malformed to spoof a short duration while containing highly dense multi-channel audio data packets.

The vulnerability is exploited by targeting the /v1/chat/completions API route with a crafted payload containing a highly compressed audio stream. Attackers can leverage the asymmetric compression capabilities of modern codecs such as FLAC, Opus, or MP3. These formats can compress minutes or hours of silent or highly repetitive audio signals into a few hundred kilobytes.

Additionally, vLLM supports inline Data URLs allowing attackers to transmit base64-encoded audio directly inside JSON objects. Since these payloads are fully self-contained, they are parsed instantly upon receipt, bypassing external network fetch timeout guards such as VLLM_AUDIO_FETCH_TIMEOUT. The decoding process allocates memory according to the formula: Samples = Sample Rate * Channels * Duration. For standard 44.1 kHz stereo audio decoded to 32-bit floating point, each second requires approximately 352.8 kilobytes of memory, allowing small files to demand gigabytes of RAM during decompression.

The primary impact of this vulnerability is a complete loss of service availability for the affected vLLM node. Because vLLM often runs as a high-performance single-process system with heavy GPU and system memory allocations, a sudden spike in RAM utilization triggers the host Linux kernel's Out-Of-Memory (OOM) killer. This terminates the core serving daemon instantly, dropping all active inference sessions and preventing new requests from being served.

The CVSS v3.1 score is evaluated at 6.5 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. Although the CVSS vector lists Privileges Required as Low (PR:L) due to standard multi-tenant API assumptions, many default vLLM deployments are exposed directly to internal networks or the open internet without authentication, making the bug practically unauthenticated. No confidentiality or integrity impact is associated with this vulnerability.

Remediation requires upgrading the vLLM engine to version 0.24.0 or higher, where the duration validation is consistently applied across all ingestion paths. For environments where immediate updates are not feasible, administrators must apply the security patches manually to the audio.py module.

In addition to upgrading, several defensive postures should be implemented:

1. Restrict Request Body Sizes: Configure reverse proxies (e.g., NGINX, Envoy, Cloudflare) to drop requests exceeding a strict threshold, such as 5MB, which prevents the transmission of extremely large base64-encoded audio buffers.

2. Adjust Environmental Limits: Set the environment variable VLLM_MAX_AUDIO_DECODE_DURATION_S to a lower value (such as 120 or 300) to restrict the maximum allowable memory allocated per-request.

3. Deploy API Gateways: Ensure that the model endpoints are protected behind an API gateway enforcing strict authentication, rate-limiting, and client quotas to mitigate bulk denial-of-service attempts.