AI Threat Alert
CVE-2026-90554: vLLM: audio decode DoS via NanoNemotronVL video input
MEDIUMThis vulnerability lets an attacker crash a vLLM inference server by uploading a tiny, highly compressed video to a NanoNemotronVL deployment running with use_audio_in_video enabled — the audio-extraction code path skips the size and duration guards (VLLM_MAX_AUDIO_DECODE_DURATION_S, VLLM_MAX_AUDIO_DECODE_BYTES) that already protect the direct-audio-upload path, so decoding a few KB of video can balloon into gigabytes of RAM and take the service down. There's no EPSS score yet, it isn't in CISA KEV, and no public exploit or Nuclei template exists — this is a freshly disclosed bug rather than an actively weaponized one — but the CVSS 3.1 score of 6.2 (AC:L/PR:N/UI:N/A:H) reflects a trivially reproducible, zero-interaction denial-of-service that requires no privileges. CISOs running multimodal vLLM deployments should treat this as a straightforward capacity-exhaustion risk on any endpoint that accepts video input, since a single malformed request can knock out a shared inference service used by multiple downstream applications or tenants. Patch to vLLM 0.28.0 immediately if NanoNemotronVL models with audio-in-video are in production; as an interim mitigation, disable use_audio_in_video, enforce request payload size caps at the API gateway, and set hard memory ceilings (cgroups/container limits) around inference workers. Watch for memory-usage spikes correlated with small multimodal payloads as a detection signal until patched.
What is the risk?
Medium severity (CVSS 6.2) with high exploitability characteristics — AC:Low, PR:None, UI:None mean any request reaching the multimodal endpoint can trigger it — but impact is bounded to availability only (C:N/I:N/A:H), no data exposure or code execution. AV:Local in the vector reflects that this is scoped to whoever can reach the vLLM inference API directly, which in practice is often a gateway-fronted internal service, but any deployment that proxies untrusted user uploads to that API inherits full remote exposure. No EPSS score, no CISA KEV listing, and no public exploit/scanner exist yet, so there is no evidence of active exploitation — this is a disclosed design gap, not an in-the-wild attack. Priority should be elevated for any org running NanoNemotronVL with audio-in-video enabled and reachable by external or multi-tenant input; otherwise, patch on the normal cycle.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Upgrade vllm to >=0.28.0, which enforces VLLM_MAX_AUDIO_DECODE_DURATION_S / VLLM_MAX_AUDIO_DECODE_BYTES on the video-derived audio extraction path (see GHSA-936p-m5pv-vvjf). 2) If immediate patching isn't possible, disable use_audio_in_video for NanoNemotronVL deployments, or block/reject video uploads from untrusted sources at the API gateway. 3) Add hard per-request payload size limits and container/cgroup memory ceilings around inference workers so a single request can't exhaust host memory. 4) Isolate multimodal inference workers so an OOM in one doesn't take down shared capacity for other tenants. 5) Monitor for anomalous memory-usage spikes correlated with small video payload sizes as a detection heuristic until patched.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-90554?
This vulnerability lets an attacker crash a vLLM inference server by uploading a tiny, highly compressed video to a NanoNemotronVL deployment running with use_audio_in_video enabled — the audio-extraction code path skips the size and duration guards (VLLM_MAX_AUDIO_DECODE_DURATION_S, VLLM_MAX_AUDIO_DECODE_BYTES) that already protect the direct-audio-upload path, so decoding a few KB of video can balloon into gigabytes of RAM and take the service down. There's no EPSS score yet, it isn't in CISA KEV, and no public exploit or Nuclei template exists — this is a freshly disclosed bug rather than an actively weaponized one — but the CVSS 3.1 score of 6.2 (AC:L/PR:N/UI:N/A:H) reflects a trivially reproducible, zero-interaction denial-of-service that requires no privileges. CISOs running multimodal vLLM deployments should treat this as a straightforward capacity-exhaustion risk on any endpoint that accepts video input, since a single malformed request can knock out a shared inference service used by multiple downstream applications or tenants. Patch to vLLM 0.28.0 immediately if NanoNemotronVL models with audio-in-video are in production; as an interim mitigation, disable use_audio_in_video, enforce request payload size caps at the API gateway, and set hard memory ceilings (cgroups/container limits) around inference workers. Watch for memory-usage spikes correlated with small multimodal payloads as a detection signal until patched.
Is CVE-2026-90554 actively exploited?
No confirmed active exploitation of CVE-2026-90554 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-90554?
1) Upgrade vllm to >=0.28.0, which enforces VLLM_MAX_AUDIO_DECODE_DURATION_S / VLLM_MAX_AUDIO_DECODE_BYTES on the video-derived audio extraction path (see GHSA-936p-m5pv-vvjf). 2) If immediate patching isn't possible, disable use_audio_in_video for NanoNemotronVL deployments, or block/reject video uploads from untrusted sources at the API gateway. 3) Add hard per-request payload size limits and container/cgroup memory ceilings around inference workers so a single request can't exhaust host memory. 4) Isolate multimodal inference workers so an OOM in one doesn't take down shared capacity for other tenants. 5) Monitor for anomalous memory-usage spikes correlated with small video payload sizes as a detection heuristic until patched.
What systems are affected by CVE-2026-90554?
This vulnerability affects the following AI/ML architecture patterns: model serving, multimodal inference pipelines.
What is the CVSS score for CVE-2026-90554?
CVE-2026-90554 has a CVSS v3.1 base score of 6.2 (MEDIUM). The EPSS exploitation probability is 0.11%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029 Denial of AI Service AML.T0034.001 Resource-Intensive Queries AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker with access to a vLLM-served NanoNemotronVL endpoint — for example, a SaaS chatbot or agent that accepts video uploads as multimodal context — crafts a small, highly compressed video file (a few KB) engineered to decode into a very long or high-bitrate audio stream. They submit it as a normal multimodal request. The server's _extract_audio_from_videos function calls load_audio_pyav(BytesIO(video_bytes)) without any duration or byte-size cap, so the full audio track is decoded into memory uncapped, consuming gigabytes of RAM from a tiny input. The inference process OOMs or becomes unresponsive, denying service to every user sharing that instance — repeatable with minimal cost per request, making it an efficient low-effort DoS lever.
Weaknesses (CWE)
CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.
- [Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- [Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H References
Timeline
Related Vulnerabilities
CVE-2024-9053 9.8 vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm CVE-2024-11041 9.8 vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllm CVE-2025-47277 9.8 vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllm CVE-2026-25960 9.8 vllm: SSRF allows internal network access
Same package: vllm CVE-2025-32444 9.8 vLLM: RCE via pickle deserialization on ZeroMQ
Same package: vllm