Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Not in CISA KEV

GHSA-936p-m5pv-vvjf — vllm

GHSA-936p-m5pv-vvjf is a Uncontrolled Resource Consumption vulnerability. A fix is available — see the affected versions and patch details below.

vLLM before 0.28.0 Denial of Service via audio extraction

Published
Sep 12, 2026
Updated
Sep 26, 2026
Affected
—
Patched
—
Exploits
None indexed
Exploitation data as of Sep 26, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-936p-m5pv-vvjf.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs9th percentile — riskier than 9% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

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.

Detection & mitigation playbook

Vulnerability
  1. Detect

    Identify every host running the affected component and compare the installed build against the fixed version below — for source-built or distro-packaged software the version string, not a lockfile, is the source of truth (`dpkg -l`, `rpm -q`, or the binary's own `--version`). Because exploitation targets the running service rather than your application code, O3 also flags the exploit behaviour from runtime telemetry and egress traffic.

  2. Fix

    Upgrade the affected component to the fixed release for GHSA-936p-m5pv-vvjf, or apply your distribution's backported patch — distro builds are often patched at an older version number, so check your vendor's advisory rather than the upstream version alone.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service. O3's runtime protection blocks the uncontrolled resource consumption flaw at execution, which holds the line on hosts you cannot patch immediately.

  4. How O3 protects you

    O3 detects and blocks GHSA-936p-m5pv-vvjf exploitation at runtime with eBPF exploit-chain detection, plus L7 egress monitoring that catches a post-exploitation callback and cuts the attacker's outbound channel.

Tailored to GHSA-936p-m5pv-vvjf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

This vulnerability has a Moderate impact on Red Hat products. When vLLM is configured to extract audio from video input for NanoNemotronVL models with `use_audio_in_video=True`, a remote attacker can provide a small, highly compressed video to trigger excessive memory allocation. This can lead to a denial of service…

Workaround published by Red Hat
To mitigate this issue, disable the `use_audio_in_video` feature if it is not required for your deployment. This prevents the vulnerable audio extraction code path from being exercised. If disabling this feature is not feasible, mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Source: Red Hat security advisory for GHSA-936p-m5pv-vvjf (CC BY 4.0)

Frequently Asked Questions

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
O3 Security · Impact-Aware SCA

Is GHSA-936p-m5pv-vvjf in your dependencies?

O3 Security finds GHSA-936p-m5pv-vvjf across dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-936p-m5pv-vvjf: vllm DoS | O3 Security