CVE-2026-90554 in vLLM
Summary
by MITRE • 09/12/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified in vLLM versions ranging from 0.10.2 up to but not including 0.28.0 represents a critical resource exhaustion flaw within the multimodal processing pipeline, specifically affecting NanoNemotronVL models when configured with audio extraction capabilities enabled via the use_audio_in_video parameter. This security defect stems from an inconsistent implementation of input validation and resource limiting mechanisms between different data ingestion paths within the framework. While direct audio uploads processed through AudioMediaIO correctly enforce limits defined by environment variables such as VLLM_MAX_AUDIO_DECODE_DURATION_S and VLLM_MAX_AUDIO_DECODE_BYTES, the code path responsible for extracting audio streams from video inputs fails to apply these same constraints. In the nano_nemotron_vl.py module, the function _extract_audio_from_videos invokes load_audio_pyav with a BytesIO object containing the extracted video bytes but omits critical parameters like max_duration_s and max_decode_bytes. This omission means that the underlying audio decoding library is allowed to operate without boundaries on memory allocation or processing time relative to input size.
From an operational perspective, this architectural inconsistency allows for a severe denial of service attack vector. An adversary can craft a malicious payload consisting of a small, highly compressed video file designed to expand significantly during decompression and audio extraction. Because the server does not limit the duration or byte count of the decoded audio stream before processing it through the model inference engine, the system is forced to allocate gigabytes of memory in an attempt to decode this artificially inflated data structure. This unbounded resource consumption rapidly exhausts available system memory on the serving host, leading to process crashes, service interruptions for legitimate users, and potential instability across the entire cluster if multiple such requests are processed concurrently. The attack does not require authentication or complex exploitation techniques beyond submitting a specific multimodal input type that triggers this vulnerable code path.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-787, regarding out-of-bounds write scenarios if the memory allocation leads to buffer overflows in lower-level libraries, though primarily it manifests as a denial of service through excessive memory usage. In terms of offensive security frameworks, this flaw is exploitable via ATT&CK technique T1496, Resource Hijacking, where an attacker consumes computational resources to degrade or deny service to other users. The root cause lies in the lack of defensive programming practices that ensure consistent validation and limiting logic across all input modalities within a unified framework. Developers must recognize that multimodal inputs often contain nested data structures, such as video files containing audio streams, which require explicit handling at every layer of extraction and processing.
Mitigation for this issue involves upgrading to vLLM version 0.28.0 or later, where the developers have corrected the discrepancy by ensuring that audio decoding operations within video inputs are subject to the same rigorous limits as direct audio uploads. For organizations unable to immediately upgrade due to dependency constraints, temporary mitigations include restricting access to multimodal endpoints for untrusted users, implementing network-level rate limiting on requests containing video payloads, and configuring host-level memory cgroups or container resource quotas to cap the maximum memory usage per process. Additionally, input validation layers should be strengthened to detect anomalously large decoded audio sizes before they are passed to the model inference engine, ensuring that even if framework limits fail, downstream safeguards can prevent catastrophic resource exhaustion.