vLLM audio flaw lets anyone crash unauthenticated servers

A security advisory published on 16 September 2026 describes an unauthenticated denial-of-service flaw in vLLM, the open-source inference server widely used to host large language models. The advisory, GHSA-hcwq-8wjf-3gcr, tracked as CVE-2026-57173, says any deployment serving an audio-capable model can be knocked over by a small, specially crafted audio file sent to the standard chat endpoint.

The root of the problem is an inconsistency, not a coding error in the decoder itself. vLLM has a guard called max_duration_s, set through the environment variable VLLM_MAX_AUDIO_DECODE_DURATION_S with a default of 600 seconds, that rejects over-long audio while it is being decoded and before memory is allocated. According to the advisory, that guard is wired into only one place: the speech-to-text serving layer behind /v1/audio/transcriptions.

The chat path never passes it. When an input_audio content part arrives at /v1/chat/completions, the advisory says the call chain runs from parse_input_audio through the media connector to load_bytes, which invokes the audio loader with no duration limit at all. Every check in the decoder is gated on the limit being present, so all of them are skipped. The result is a classic decompression bomb: the advisory states that a few kilobytes of compressed audio can expand into multiple gigabytes of float32 PCM data at decode time, which then kills the worker process with an out-of-memory error.

Two details make the issue easier to exploit. First, inline data: URLs are decoded locally, so the separate VLLM_AUDIO_FETCH_TIMEOUT setting does not bound them. Second, the advisory notes that vLLM's OpenAI-compatible server has no authentication by default; it only requires a key if an operator sets --api-key or VLLM_API_KEY. An exposed server therefore accepts the request from anyone who can reach it.

The advisory classifies the impact as unauthenticated remote denial of service through memory amplification, mapped to CWE-770 and CWE-409, which cover unrestricted resource allocation and improper handling of compressed data. It places the bug in the same family as two siblings in vLLM's media subsystem: CVE-2026-5497, a video frame-count bomb in VideoMediaIO.load_base64, and GHSA-pq5c-rjhq-qp7p, the image equivalent. The advisory describes the impact as the same class and severity as the video case.

The finding was verified against the main branch at commit d78650c, dated 16 June 2026, and the advisory says it applies to the latest release, v0.23.0. A fix has been introduced in pull request 45908 in the vLLM project repository.

For teams running agent stacks, the practical lesson in the advisory is about where guards are attached rather than whether they exist. The duration check was written, tested and enabled by default, but it sat in the transcription service instead of the decoder, so a second caller inherited none of the protection. Operators running audio-capable models on vLLM should apply the fix and, on the evidence of the advisory's note about default settings, check whether their OpenAI-compatible endpoint is reachable without an API key.