CVE-2026-114052: vLLM unauthenticated /tokenize

CISO Take

vLLM versions after 0.24.0 and before 0.31.0 cache a processor for every distinct request-controlled mm_processor_kwargs value in an unbounded dictionary when serving MOSS-Audio models. Unauthenticated attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key, so a single network client can drive the host out of memory and crash the API process. There is no EPSS score, KEV listing, public exploit or Nuclei template yet, but the attack needs no privileges, no user interaction and no AI/ML expertise, so weaponization would be trivial once the advisory is read. The exposure is limited to deployments that serve MOSS-Audio models on an affected version, but those that do should treat any network-reachable instance as at risk, even one that relies on --api-key. Upgrade to vLLM 0.31.0 or later, and until then block or authenticate the /tokenize route at a reverse proxy and keep inference endpoints off untrusted networks.

Sources:NVDGitHub AdvisoryVulnCheckATLAS

What is the risk?

High (CVSS 7.5, AV:N/AC:L/PR:N/UI:N), availability impact only. Exploitation is simple and repeatable: each request with a new mm_processor_kwargs value grows the cache, so memory consumption is cumulative and attacker-controlled. No confidentiality or integrity impact is reported. Exploitation likelihood is currently unquantified because EPSS is N/A and no public exploit or scanner template exists, but the simplicity of the flaw makes rapid weaponization plausible. Exposure is narrowed to deployments serving MOSS-Audio models on vLLM after 0.24.0 and before 0.31.0. The --api-key bypass on /tokenize removes the main compensating control operators usually rely on. Confidence: MEDIUM, because the assessment rests on the advisory description with no exploitation telemetry.

How does the attack unfold?

Initial Access

Attacker reaches the exposed vLLM /tokenize endpoint over the network, with no credentials needed because it bypasses --api-key.

AML.T0049

Exploitation

Attacker sends many requests with distinct or oversized mel_config values in mm_processor_kwargs, each adding a processor to the unbounded cache.

AML.T0034.001

Impact

Host memory is exhausted and the vLLM API process crashes, denying inference service to all users.

AML.T0029

Initial Access

Attacker reaches the exposed vLLM /tokenize endpoint over the network, with no credentials needed because it bypasses --api-key.

AML.T0049

Exploitation

Attacker sends many requests with distinct or oversized mel_config values in mm_processor_kwargs, each adding a processor to the unbounded cache.

AML.T0034.001

Impact

Host memory is exhausted and the vLLM API process crashes, denying inference service to all users.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
95.4K94 dependentsPushed 6d ago27% patched~37d to patchFull package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 41% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vLLM to 0.31.0 or later (the fixed release per the GHSA advisory GHSA-823j-m4cj-hmjf). 2) If you cannot upgrade immediately, block /tokenize at the reverse proxy or API gateway, or require authentication there, because the built-in --api-key does not protect this route. 3) Do not expose vLLM directly to the internet; restrict access to trusted networks and apply per-client rate limits and request body size limits. 4) Set container or cgroup memory limits and auto-restart policies so a crash does not take down the host, and alert on abnormal RSS growth. 5) Detect: monitor access logs for repeated /tokenize requests with varied or oversized mm_processor_kwargs/mel_config values from the same source, and alert on OOM kills of vLLM processes. 6) Inventory deployments to confirm whether any serve MOSS-Audio models.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoSInferenceAPIAML.T0029- Denial of AI Service AML.T0034.001- Resource-Intensive Queries AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Respond to previously unknown risks and ensure mechanisms to supersede or deactivate AI systems

OWASP LLM Top 10

LLM10:2025-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-114052?

vLLM versions after 0.24.0 and before 0.31.0 cache a processor for every distinct request-controlled mm_processor_kwargs value in an unbounded dictionary when serving MOSS-Audio models. Unauthenticated attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key, so a single network client can drive the host out of memory and crash the API process. There is no EPSS score, KEV listing, public exploit or Nuclei template yet, but the attack needs no privileges, no user interaction and no AI/ML expertise, so weaponization would be trivial once the advisory is read. The exposure is limited to deployments that serve MOSS-Audio models on an affected version, but those that do should treat any network-reachable instance as at risk, even one that relies on --api-key. Upgrade to vLLM 0.31.0 or later, and until then block or authenticate the /tokenize route at a reverse proxy and keep inference endpoints off untrusted networks.

Is CVE-2026-114052 actively exploited?

No confirmed active exploitation of CVE-2026-114052 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-114052?

1) Upgrade vLLM to 0.31.0 or later (the fixed release per the GHSA advisory GHSA-823j-m4cj-hmjf). 2) If you cannot upgrade immediately, block /tokenize at the reverse proxy or API gateway, or require authentication there, because the built-in --api-key does not protect this route. 3) Do not expose vLLM directly to the internet; restrict access to trusted networks and apply per-client rate limits and request body size limits. 4) Set container or cgroup memory limits and auto-restart policies so a crash does not take down the host, and alert on abnormal RSS growth. 5) Detect: monitor access logs for repeated /tokenize requests with varied or oversized mm_processor_kwargs/mel_config values from the same source, and alert on OOM kills of vLLM processes. 6) Inventory deployments to confirm whether any serve MOSS-Audio models.

What systems are affected by CVE-2026-114052?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference servers, multimodal/audio pipelines, shared inference gateways.

What is the CVSS score for CVE-2026-114052?

CVE-2026-114052 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.48%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference serversmultimodal/audio pipelinesshared inference gateways

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

AML.T0034.001Resource-Intensive Queries

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker finds a network-reachable vLLM server hosting a MOSS-Audio model, for example via exposed ports or an internal pivot. They script a loop of POST requests to /tokenize, each with a distinct or very large mel_config value inside mm_processor_kwargs. The server builds and permanently caches a new processor for each unique value, so memory grows without bound even though --api-key is set. Within minutes the host runs out of memory and the vLLM API process is killed, interrupting every application that depends on the inference service. The attacker can repeat the loop each time the service restarts.

Weaknesses (CWE)

CWE-770Allocation of Resources Without Limits or ThrottlingPrimary CWE-770Allocation of Resources Without Limits or Throttling

CWE-770 — Allocation of Resources Without Limits or Throttling: The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

[Requirements] Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
[Architecture and Design] Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Source: MITRE CWE corpus.