Answer in brief
CVE-2026-90554 records a Unknown severity vulnerability in vLLM before 0.28.0 Denial of Service via audio extraction. The current sources do not mark it as known exploited. The current feed maps vllm-project/vLLM (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps vllm-project/vLLM (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| vllm-project/vLLMgeneric | >=0.10.2 <0.28.0 | 0.28.0 |
Published upstream
Sep 12, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 12, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 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.
Quoted source text, attributed separately from HOL analysis.