vllm: Multimodal chat audio decoding bypasses the decompression-bomb duration limit

Summary

Multimodal chat audio decoding bypasses the decompression-bomb duration limit.

Technical Details

vLLM's current head contains the fix for GHSA-6pr9-rp53-2pmc / CVE-2026-54233, which adds VLLM_MAX_AUDIO_DECODE_DURATION_S and wires that decoded-duration guard into the /v1/audio/transcriptions preprocessing path. The same decoded-size guard is not applied to the shared multimodal AudioMediaIO path used by OpenAI chat audio inputs.

As a result, /v1/chat/completions requests containing input_audio data URLs or audio_url media can still reach AudioMediaIO.load_bytes() and AudioMediaIO.load_file(), both of which call load_audio(..., sr=None) with no max_duration_s bound. The decoder now supports metadata and decoded-sample duration limits, but the chat media path never passes the limit.

This is a sibling/incomplete-fix variant of the published audio decompression-bomb issue. The published advisory and fix PR are scoped to speech-to-text; this report covers the separate multimodal chat audio ingestion path.

The decoder fix added duration-limit support to load_audio(), load_audio_soundfile(), and load_audio_pyav().

The speech-to-text path uses that guard:

y, sr = load_audio(
    buf,
    sr=self.asr_config.sample_rate,
    max_duration_s=self.max_audio_decode_duration_s,
)

The chat multimodal path does not:

def load_bytes(self, data: bytes) -> tuple[npt.NDArray, float]:
    return load_audio(BytesIO(data), sr=None)

def load_file(self, filepath: Path) -> tuple[npt.NDArray, float]:
    return load_audio(filepath, sr=None)

MediaConnector.fetch_audio() constructs AudioMediaIO, and chat_utils.py routes both audio_url and input_audio content parts to this path.

The merged speech-to-text fix PR explicitly left existing callers unaffected because max_duration_s defaults to None. AudioMediaIO is one of those callers and still invokes the decoder without opting in to the guard.

Impact

Medium

• CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

An attacker who can submit chat completion requests to an audio-capable vLLM deployment can provide a small compressed audio input that expands to very large decoded PCM. The decoder accumulates decoded frames before model-level audio clip limits run, which can exhaust memory or materially degrade availability.

This does not require a large request body when the payload is supplied as an audio_url, and the input_audio path is also affected for compressed audio that fits within normal request size limits.

--allowed-media-domains, media fetch timeouts, and HTTP body limits may reduce some delivery options, but they do not enforce a decoded PCM duration/sample budget. The issue remains reachable for allowed audio_url domains and for input_audio data that fits within normal request limits.

This report uses Medium / PR:L to match vLLM's prior audio decompression-bomb advisory and vLLM's policy category for DoS-only issues. If a deployment exposes chat completions without API-key authentication, the same technical issue may be assessed with PR:N.

Suggested Fix

Apply the decoder duration guard inside AudioMediaIO, not only in the speech-to-text endpoint:

• add a validated max_duration_s field to AudioMediaIO;
• default it to envs.VLLM_MAX_AUDIO_DECODE_DURATION_S;
• pass it from load_bytes() and load_file() into load_audio(...);
• prevent untrusted request-level media_io_kwargs["audio"] from disabling or raising the server-side cap beyond operator policy;
• add regression coverage for AudioMediaIO, MediaConnector.fetch_audio(), and chat input_audio/audio_url.

Affected Package/Versions

• Ecosystem: pip
• Package: vllm
• Confirmed affected range: >= 0.19.0, < 0.24.0
• Patched version: 0.24.0

Appendix: Evidence Files

• report.md
• validation.md
• duplicate-research.md
• severity-and-intended-behavior-validation.md
• suggested-fix.md