CVE-2026-90554 is a medium severity (6.2) denial of service in vLLM versions from 0.10.2 up to, but not including, 0.28.0. A small, highly compressed video can force the server to allocate gigabytes of memory when audio is extracted for NanoNemotronVL models. Upgrade to vLLM 0.28.0.
What's affected
The record and the GitHub advisory agree: vLLM at 0.10.2 or later and before 0.28.0, with 0.28.0 the fixed release. The problem only appears when a NanoNemotronVL model is served with the use_audio_in_video option turned on. If you do not serve that model family, or have that option off, this path is not in use.
The record's vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, which is a local attack vector. That is why the score is 6.2 and not higher. In practice a multimodal service that takes untrusted video from callers can still feel it, so read the vector as the scorer's view, not a guarantee about your deployment. VulnCheck shows a CVSS v4 score of 6.9, also medium. The GitHub advisory lists no CWE; the NVD record uses CWE-400, uncontrolled resource consumption.
How to check if you're exposed
Check the installed version:
pip show vllm
Then check your launch configuration and application code for the NanoNemotronVL model and for use_audio_in_video=True. If you serve other models only, you are outside the affected path, though upgrading is still sensible.
If you do serve this model, ask where video inputs come from. Anything that accepts video from outside your trust boundary is the case the advisory worries about.
Paste a lockfile or SBOM into the free in-browser dependency scan to see whether this package is in your tree, including as a transitive dependency. Safeguard's reachability analysis can then show whether your code actually calls the affected path, which helps you order the work.
What to do now
- Upgrade vLLM to 0.28.0 or later.
- If you cannot upgrade yet, turn off audio extraction from video for this model, or stop accepting untrusted video input.
- Set memory limits on the serving container so one request cannot take the whole host.
- Add request size and duration limits at the gateway in front of the model server.
Why it matters
The advisory points to an inconsistency inside vLLM. Direct audio uploads go through a code path that enforces two limits, a maximum decode duration and a maximum decode size, both set by environment variables. The video path calls the same audio loader without passing either limit, so neither variable has any effect.
This is a recurring pattern: one input route gets a safety check, a sibling route does not. A compressed file that expands to a large amount of data is the classic way to turn a small request into a large allocation. The KEV flag in the record is false and no source we read reports exploitation.
Try it yourself
When a fixed release exists, the fastest win is knowing which of your packages have one. This demo shows how to find fixes you can apply today.
Click through it at your own pace, or open it full screen.
Quick check
Does every vLLM deployment need to act?
The advisory ties the issue to NanoNemotronVL with audio in video enabled. Others are not on the affected path, but upgrading is low risk compared with tracking exceptions.
Why does the score say local attack vector?
That is how the record's CVSS vector is written. It is the NVD scorer's judgment, so assess your own exposure by who can submit video to your server.
Sources
Last reviewed: 18 October 2026.
