CVE-2026-57173: vLLM Audio Processing DoS Vulnerability

CVE-2026-57173 Overview

CVE-2026-57173 affects vLLM, an inference and serving engine for large language models. The vulnerability resides in the input_audio handling path for /v1/chat/completions requests. This path calls AudioMediaIO.load_bytes or AudioMediaIO.load_file without passing the VLLM_MAX_AUDIO_DECODE_DURATION_S guard to the shared audio decoder. A client can submit a small compressed audio payload that expands into a very large float32 PCM allocation, crashing the worker process with an out-of-memory condition. The flaw is classified under [CWE-770] Allocation of Resources Without Limits or Throttling. The issue is fixed in vLLM version 0.24.0.

Critical Impact
A single crafted audio payload sent to an audio-capable vLLM deployment can exhaust worker memory and terminate the inference process, causing service disruption for all users of the affected model.

Affected Products

vLLM versions prior to 0.24.0
Deployments serving an audio-capable model exposing /v1/chat/completions
Endpoints accepting inline data URLs via input_audio (not bounded by VLLM_AUDIO_FETCH_TIMEOUT)

Discovery Timeline

2026-09-16 - CVE-2026-57173 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-57173

Vulnerability Analysis

The vulnerability stems from inconsistent enforcement of decode limits across vLLM API paths. The /v1/audio/transcriptions endpoint already enforces the VLLM_MAX_AUDIO_DECODE_DURATION_S guard through the shared audio decoder. The /v1/chat/completions endpoint accepts audio through the input_audio content type but invokes AudioMediaIO.load_bytes or AudioMediaIO.load_file without forwarding that duration limit. Compressed audio codecs achieve high compression ratios, so a small request body can decode into a very large uncompressed float32 PCM buffer. The decoder allocates that buffer in worker memory before any downstream validation runs. When the resulting allocation exceeds available memory, the worker process crashes and terminates in-flight requests. Authentication does not eliminate the risk; it only limits which clients can reach the endpoint.

Root Cause

The root cause is a missing parameter in the call chain between the chat completions handler and the shared audio decoder. The decoder supports a duration cap, but the chat path did not pass VLLM_MAX_AUDIO_DECODE_DURATION_S when invoking load_bytes or load_file. Inline data URLs additionally bypass the VLLM_AUDIO_FETCH_TIMEOUT guard, which normally bounds network fetches.

Attack Vector

An attacker with network access to an audio-capable vLLM deployment sends a /v1/chat/completions request containing an input_audio payload. The payload is a small compressed audio buffer, delivered inline as a data URL, that decodes into a multi-gigabyte float32 PCM array. The worker process attempts the allocation, exhausts memory, and crashes.

python

 import pybase64
 import torch
 
+import vllm.envs as envs
 from vllm.logger import init_logger
 from vllm.multimodal.audio import resample_audio_pyav
 from vllm.utils.import_utils import PlaceholderModule
# Source: https://github.com/vllm-project/vllm/commit/3d20275bb4d434f53055c3c0b645fd8bb072965e
# The patch imports vllm.envs so AudioMediaIO can read
# VLLM_MAX_AUDIO_DECODE_DURATION_S and enforce it in the chat completions path.

Detection Methods for CVE-2026-57173

Indicators of Compromise

Repeated worker process crashes or restarts on vLLM inference nodes correlated with /v1/chat/completions requests.
Out-of-memory (OOM) kill events in kernel logs (dmesg, journalctl) on hosts running vLLM workers.
/v1/chat/completions request bodies containing input_audio fields with inline data:audio/*;base64,... URLs from unexpected clients.

Detection Strategies

Instrument the vLLM API server to log audio payload sizes and decoded PCM durations for input_audio requests.
Alert when decoded audio duration exceeds the value defined by VLLM_MAX_AUDIO_DECODE_DURATION_S.
Correlate worker restart events with recent request identifiers to attribute crashes to specific payloads.

Monitoring Recommendations

Track resident set size (RSS) and allocation spikes on vLLM worker processes with per-request granularity.
Monitor HTTP 5xx rates and request timeouts on /v1/chat/completions for audio-capable models.
Forward vLLM application logs and host OOM events into a centralized analytics pipeline for correlation.

How to Mitigate CVE-2026-57173

Immediate Actions Required

Upgrade vLLM to version 0.24.0 or later on all deployments serving audio-capable models.
Restrict network access to /v1/chat/completions using authentication and network-layer allowlists until patching is complete.
Set request body size limits at the reverse proxy or ingress layer to reject oversized audio payloads.

Patch Information

The fix landed in vLLM 0.24.0. The patch imports vllm.envs inside vllm/multimodal/media/audio.py and enforces VLLM_MAX_AUDIO_DECODE_DURATION_S in the chat completions audio path. See the GitHub Security Advisory GHSA-hcwq-8wjf-3gcr, the fix commit, the associated pull request #45908, and the v0.24.0 release notes.

Workarounds

Disable audio-capable models on internet-facing vLLM deployments until the upgrade is applied.
Enforce a reverse-proxy body-size limit sized to plausible legitimate audio inputs.
Explicitly set VLLM_MAX_AUDIO_DECODE_DURATION_S and VLLM_AUDIO_FETCH_TIMEOUT to conservative values.
Run vLLM workers under cgroup memory limits so an OOM condition terminates only the offending worker without cascading failures.

bash

# Configuration example: enforce conservative audio decode and fetch bounds
export VLLM_MAX_AUDIO_DECODE_DURATION_S=30
export VLLM_AUDIO_FETCH_TIMEOUT=10

# Upgrade vLLM to the fixed version
pip install --upgrade "vllm>=0.24.0"

# Verify installed version
python -c "import vllm; print(vllm.__version__)"