Description

vLLM versions >=0.10.2 and <0.28.0 do not apply any audio decode-size or duration limit when extracting audio from video input for NanoNemotronVL models. In nano_nemotron_vl.py, _extract_audio_from_videos calls load_audio_pyav(BytesIO(video_bytes)) without the max_duration_s or max_decode_bytes parameters, so neither VLLM_MAX_AUDIO_DECODE_DURATION_S nor VLLM_MAX_AUDIO_DECODE_BYTES is enforced (unlike the direct audio upload path in AudioMediaIO). When a NanoNemotronVL model is served with use_audio_in_video=True, an attacker who supplies a small, highly compressed video as multimodal input can force the server to allocate gigabytes of memory during audio decoding, resulting in a denial of service. Fixed in vLLM 0.28.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.2",
  "pubDate": "2026-09-12T13:16:54.040Z",
  "pubdate": "2026-09-12T13:16:54.040Z",
  "executiveSummary": "A Denial of Service (DoS) vulnerability exists in vLLM versions 0.10.2 through 0.27.x due to improper resource constraints during audio extraction from video inputs in NanoNemotronVL models.\nThe vulnerability occurs because the `_extract_audio_from_videos` function fails to enforce security limits on audio decode duration and byte size when processing multimodal input.\nAn unauthenticated attacker can exploit this by submitting a specially crafted, highly compressed video file.\nUpon processing, the server attempts to decode the embedded audio stream without memory or duration restrictions, leading to uncontrolled memory allocation.\nThis behavior can result in excessive memory consumption (gigabytes), potentially crashing the vLLM instance or starving other system processes of resources.\nThis flaw is specific to deployments utilizing the `use_audio_in_video=True` configuration.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the `_extract_audio_from_videos` function located in `nano_nemotron_vl.py` within the vLLM codebase. While the dedicated `AudioMediaIO` path for direct audio uploads correctly utilizes `load_audio_pyav` with security-conscious parameters—specifically `max_duration_s` and `max_decode_bytes`—the video-based audio extraction path omits these critical safeguards.\nThe vulnerability allows an attacker to bypass global configuration limits defined by `VLLM_MAX_AUDIO_DECODE_DURATION_S` and `VLLM_MAX_AUDIO_DECODE_BYTES` during the inference pipeline. When a user provides a small, highly compressed video file, the PyAV backend attempts to decompress and decode the underlying audio stream. Without size or duration limits, the decoder allocates memory based on the decompressed output rather than the compressed input size.\nThe attack flow proceeds as follows: 1) An attacker crafts a malicious input file, such as a video containing an audio stream designed to expand to an exceptionally large size during decompression. 2) The attacker submits this file to a vLLM deployment where `use_audio_in_video` is enabled. 3) The `_extract_audio_from_videos` function receives the video bytes via `BytesIO`. 4) The function invokes `load_audio_pyav(BytesIO(video_bytes))` without passing the necessary memory-limiting parameters. 5) The underlying decoding library consumes system memory proportional to the inflated audio data, leading to memory exhaustion.\nThis vulnerability is reachable by any user capable of submitting multimodal requests to the model, requiring no specific authentication or elevated privileges. Because the resource exhaustion occurs during the decoding phase of the request processing, it effectively blocks the vLLM worker process from handling subsequent legitimate requests, resulting in a persistent DoS state. The vulnerability affects vLLM versions >=0.10.2 and <0.28.0. The lack of validation ensures that even small, seemingly innocuous inputs can trigger massive resource spikes, making this an effective vector for disrupting service availability in production environments."
}