Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach exposed vLLM /tokenize endpoint
-
DeliverySend request with distinct oversized mel_config
-
ExploitBypass --api-key authentication control
-
ExecutionCache new processor in unbounded dict
-
PersistRepeat to exhaust host memory
-
ImpactCrash API process (denial of service)
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 | The target vLLM instance (version after 0.24.0 and before 0.31.0) must be serving the MOSS-Audio model and expose the HTTP /tokenize endpoint to the attacker. The attacker supplies distinct or oversized mel_config values via request-controlled mm_processor_kwargs, each of which is cached in an unbounded per-processor dictionary. Critically, no authentication limits this attack: the description states the /tokenize endpoint bypasses --api-key, so even deployments configured with an API key are exploitable. The main limiting factors are network reachability of the API and whether the MOSS-Audio model is actually deployed; versions at or above 0.31.0, or deployments not serving this model, are not affected. |
| Impact | This is a credible availability-focused priority for anyone running the affected feature, though not a universal emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated attack with no user interaction, and the impact is confined to availability (VA:H; VC:N/VI:N/VA:H) - consistent with CWE-770 unbounded resource allocation and with the description's host-memory-exhaustion/process-crash outcome. The score of 8.7 is driven entirely by ease of access plus high availability impact, with zero confidentiality or integrity impact, so this is a classic DoS rather than a code-execution or data-exposure flaw. A critical aggravating factor explicitly stated in the description is that the vulnerable /tokenize endpoint BYPASSES the --api-key control, meaning deployments that believe they are authentication-gated are in fact exposed - this raises real-world risk above what the raw vector alone conveys. No EPSS score, KEV listing, or POC is present in the provided data, so there is no evidence of active exploitation or public exploit code; the likelihood signals are therefore unknown rather than confirmed-low. Net: treat as a genuine patch-worthy DoS for exposed vLLM instances serving the MOSS-Audio model, but it is not an RCE and its practical blast radius depends on whether that specific model/endpoint is reachable. |
| Exploit ScenarioDerived | An attacker who can reach a vLLM server's HTTP API serving the MOSS-Audio model sends repeated requests to the /tokenize endpoint, each carrying a distinct or oversized mel_config value inside mm_processor_kwargs. Because this endpoint is not protected by --api-key, no credentials are needed; each unique value causes a new processor to be cached in an unbounded dictionary, steadily consuming host memory until the API process is exhausted and crashes. No public exploit code is identified at time of analysis, but the attack requires only crafted HTTP requests and no special tooling. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Unauthenticated memory exhaustion in vLLM versions after 0.24.0 and before 0.31.0 can crash the API process when the MOSS-Audio model is served, because request-controlled mm_processor_kwargs values are cached in an unbounded dictionary. Attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key authentication, steadily consuming host memory until the service dies. No public exploit identified at time of analysis; the vendor-released fix is vLLM 0.31.0, and only deployments actively serving MOSS-Audio with a reachable /tokenize endpoint are exposed.
RemediationAI
Vendor-released patch: upgrade to vLLM 0.31.0 or later, which removes the unbounded caching behavior; see GHSA-823j-m4cj-hmjf. If immediate upgrade is not possible, remove the MOSS-Audio model from served models or disable the /tokenize endpoint entirely (e.g., via reverse-proxy route blocking) - this eliminates the vulnerable feature but breaks audio tokenization workflows. Because /tokenize bypasses --api-key, setting an API key is not a mitigation. As a temporary containment measure, restrict network access to the vLLM HTTP API to trusted clients and apply request-size and rate limits at a reverse proxy; note that rate limiting only slows the memory growth from distinct mm_processor_kwargs values and does not eliminate the unbounded-cache condition, so it should be paired with memory limits/restart supervision and close monitoring for OOM events.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
vLLM is a high-throughput LLM inference and serving engine. In the affected releases, the MOSS-Audio multimodal pipeline caches a processor instance for every distinct request-supplied mm_processor_kwargs value, including mel_config (mel-spectrogram parameters), using a dictionary with no size bound or eviction policy. This is CWE-770 (Allocation of Resources Without Limits or Throttling): each unique or oversized configuration creates a new persistent cache entry, so memory grows monotonically with attacker-controlled requests. The /tokenize endpoint is intended for tokenizer operations but accepts these kwargs and, per the advisory, bypasses the --api-key check, meaning an unauthenticated remote attacker (CVSS 4.0 AV:N/AC:L/PR:N/UI:N) can drive the process to OOM and crash. Impact is limited to availability (VA:H) with no confidentiality or integrity effect, and only MOSS-Audio-serving instances are affected.
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
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Unauthenticated network requests (PR:N/AV:N/AC:L) to an api-key-bypassing endpoint cause memory exhaustion with only availability impact (A:H; C:N/I:N), scope unchanged.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
vLLM after 0.24.0 and before 0.31.0 contains a memory exhaustion vulnerability in MOSS-Audio model serving that caches a processor for every distinct request-controlled mm_processor_kwargs value in an unbounded dictionary. Unauthenticated attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key, to exhaust host memory and crash the API process.
Technical POC Analysis
CWE-770: Allocation of Resources Without Limits or Throttling.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Organizations running vLLM for MOSS-Audio inference face a high-severity availability risk: crafted requests to the /tokenize endpoint can drive uncontrolled memory growth and take the API service down, interrupting AI-dependent workflows. Leadership should prioritize this for exposed AI platforms because vulnerable versions are after 0.24.0 and before 0.31.0, the vendor fix is vLLM 0.31.0, and while no public exploit has been identified at time of analysis, the business disruption from service loss is immediate for affected teams.
Apply vendor patch.
Threat Intelligence Overview
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.
Related Vulnerabilities in vLLM Cache and Resource Consumption Vulnerabilities
View all 7vLLM 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
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat
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
Vllm versions up to 0.12.0 is affected by allocation of resources without limits or throttling (CVSS 6.5).
EUVD-2026-107003
GHSA-h4cj-w5f7-mjp3
NVD
CVE.org
EPSS
Exploit-DB