EUVD-2026-80880
GHSA-hcwq-8wjf-3gcr
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach audio-capable vLLM /v1/chat/completions
-
DeliverySubmit small compressed input_audio data URL
-
ExploitDecoder skips duration guard, expands to huge PCM
-
Executionfloat32 allocation exhausts memory
-
ImpactWorker OOM crash / service unavailable
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource allocation limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a vLLM deployment (<0.24.0) that serves an audio-capable model and exposes the /v1/chat/completions endpoint accepting input_audio. The specific trigger is the input_audio handling path, which calls AudioMediaIO.load_bytes/load_file without passing VLLM_MAX_AUDIO_DECODE_DURATION_S, and inline data URLs additionally bypass VLLM_AUDIO_FETCH_TIMEOUT. The primary limiting factor is deployment shape: only audio-capable model servers are affected, and network reachability plus any front-of-service authentication gate determines who can send the request - the description states an unauthenticated client can exploit it and that authentication only affects deployment-specific reachability, so authentication is a limiting control the operator may or may not have in place. No user interaction is required. |
| Impact | All signals point to a genuine but bounded availability-only issue. The CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, 6.5) correctly captures network reachability, low complexity, and pure availability impact with no confidentiality or integrity effect (C:N/I:N). Exploitation status: no public exploit identified at time of analysis - there is no CISA KEV listing and no POC referenced (only the advisory, fixing PR #45908, the fix commit, and the 0.24.0 release are provided). EPSS and SSVC data were not supplied, so probability-of-exploitation and automatability cannot be quantified from the input. There is a notable internal conflict on privileges: the vendor vector encodes PR:L (authenticated), but the description explicitly states 'An unauthenticated client can therefore submit a small compressed audio input' and that 'authentication changes only the deployment-specific reachability' - i.e., a default audio-capable deployment is exploitable without credentials. This means the effective privilege requirement is deployment-dependent and, for typical open serving endpoints, closer to PR:N - verify against your specific deployment. Net: this is a real, easy-to-trigger DoS against a widely-used inference engine, but it is not a critical RCE/data-exposure priority; treat it as a medium-severity patch-soon item, elevated where the vLLM endpoint is internet-facing and audio-capable. |
| Exploit ScenarioDerived | An attacker locates a vLLM server hosting an audio-capable model and sends a /v1/chat/completions request containing an input_audio inline data URL with a small, highly-compressed audio payload. The decoder expands it into a very large float32 PCM buffer because the input_audio path never passes VLLM_MAX_AUDIO_DECODE_DURATION_S, exhausting memory and crashing the worker; inline data URLs also skip the VLLM_AUDIO_FETCH_TIMEOUT bound. No public exploit code is referenced, but the technique is simple and repeatable for denial of service. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 16, 2026
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat/completions input_audio path, because that code path decodes audio without the VLLM_MAX_AUDIO_DECODE_DURATION_S guard already enforced on /v1/audio/transcriptions - an unbounded resource allocation flaw (CWE-770) that expands a tiny compressed file into a very large float32 PCM buffer. The issue affects every vLLM release prior to 0.24.0 that serves an audio-capable model and exposes the chat completions endpoint, with inline data URLs additionally escaping VLLM_AUDIO_FETCH_TIMEOUT; impact is availability-only (no confidentiality or integrity loss). Per the assessed vector the attack is remote and unauthenticated (PR:N, UI:N), while the vendor-published vector scores it PR:L, so whether any front-of-service authentication gate exists is deployment-specific; at time of analysis no public exploit code and no confirmed active exploitation were identified, and a vendor patch exists in 0.24.0.
RemediationAI
Vendor-released patch: upgrade to vLLM 0.24.0, which threads max_duration_s=envs.VLLM_MAX_AUDIO_DECODE_DURATION_S into AudioMediaIO.load_bytes and AudioMediaIO.load_file (PR 45908, commit 3d20275bb4d434f53055c3c0b645fd8bb072965e); the release is at https://github.com/vllm-project/vllm/releases/tag/v0.24.0 and the advisory at https://github.com/vllm-project/vllm/security/advisories/GHSA-hcwq-8wjf-3gcr. If upgrading immediately is not possible, the highest-value compensating control is to stop accepting the vulnerable input on the affected path: put an ingress rule or reverse proxy in front of /v1/chat/completions that rejects requests containing input_audio (or rejects audio/* content types and data: URLs in the messages array) while audio is not needed - the trade-off is loss of audio chat capability, and the rule must be maintained as request schemas evolve. A second control is to clamp the maximum HTTP request body size (and JSON depth) for the chat completions endpoint; because the attack uses a small compressed payload with high expansion, this only helps against the largest inline base64 blobs and will also block legitimately large multimodal requests, so it is a partial mitigation rather than a fix. Setting VLLM_AUDIO_FETCH_TIMEOUT or VLLM_MAX_AUDIO_DECODE_DURATION_S does not protect this code path in unpatched versions, since those environment variables are not consulted by load_bytes/load_file here. Requiring authentication at the front door reduces who can reach the endpoint but, as the advisory states, changes only deployment-specific reachability and does not remediate the defect - it fails entirely in multi-tenant or proxy-authenticated environments where any admitted user can send the request. Finally, run the inference worker under a constrained cgroup/container memory limit so a malicious decode triggers an OOM kill of only that worker rather than the node; the trade-off is reduced throughput headroom and forced worker restarts, and the platform supervisor must be able to restart the process cleanly.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
vLLM is an open-source inference and serving engine for large language models that exposes OpenAI-compatible REST endpoints; its multimodal stack routes audio content through vllm/multimodal/media/audio.py, where AudioMediaIO.load_bytes and AudioMediaIO.load_file decode raw or base64 payloads via the shared load_audio helper (backed by a soundfile/decoder layer) into float32 PCM arrays. In versions before 0.24.0 these two methods called load_audio(BytesIO(data), sr=None) or load_audio(filepath, sr=None) without forwarding vllm.envs.VLLM_MAX_AUDIO_DECODE_DURATION_S, so the duration cap that protects /v1/audio/transcriptions was silently absent on the chat-completions input_audio path, and inline data: URLs reached the decoder without being bounded by VLLM_AUDIO_FETCH_TIMEOUT. Because compressed audio formats can achieve very high expansion ratios, a few kilobytes of attacker-supplied audio can produce an allocation far larger than the request itself - the classic CWE-770 'Allocation of Resources Without Limits or Throttling' pattern in which no per-request ceiling constrains the derived buffer size. The upstream fix (PR 45908, commit 3d20275bb4d434f53055c3c0b645fd8bb072965e, released in v0.24.0) simply threads max_duration_s=envs.VLLM_MAX_AUDIO_DECODE_DURATION_S into both load_audio call sites, applying the same decode-duration ceiling the transcription endpoint already used. Note that the CPE cpe:2.3:a:vllm-project:vllm:*:*:*:*:*:*:*:* is version-agnostic, so all vLLM builds must be assumed affected unless confirmed to be 0.24.0 or later.
Know when Vllm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Description states unauthenticated exploitation by default (PR:N), remote and low-complexity, with pure availability impact (A:H) and no confidentiality/integrity effect; auth is a deployment-specific control.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
vLLM is an inference and serving engine for large language models. Prior to 0.24.0, the input_audio handling path for /v1/chat/completions calls AudioMediaIO.load_bytes or AudioMediaIO.load_file without passing VLLM_MAX_AUDIO_DECODE_DURATION_S to the shared audio decoder. An unauthenticated client can therefore submit a small compressed audio input that expands into a very large float32 PCM allocation, bypassing the duration guard already used by /v1/audio/transcriptions and causing an out-of-memory worker crash. Inline data URLs reach this path without being bounded by VLLM_AUDIO_FETCH_TIMEOUT. The issue affects deployments serving an audio-capable model, and authentication changes only the deployment-specific reachability. This issue is fixed in version 0.24.0.
Blast Radius
ecosystem impact- 4 pypi packages depend on vllm (4 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.24.0.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the sh
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Memory exhaustion in vLLM 0.22.0-0.23.0 allows authenticated API callers to crash or destabilize the inference server by
Exploit-DB