CVE-2026-105759: vLLM: unbounded metrics labels allow memory-exhaustion DoS

HIGHPoC AVAILABLE

Published October 5, 2026

CISO Take

vLLM's Rust frontend records the raw HTTP method of each request as a Prometheus label. An unauthenticated attacker can send requests with unique, made-up method names to routes such as /tokenize. Each one permanently creates new metric series, so memory use and the /metrics response grow until the service or its monitoring path fails. The CVSS score is a moderate 5.9 because the attack needs no privileges but is rated high complexity. EPSS is low at 0.33%, which puts it in the top 76th percentile. It is not in CISA KEV, and we found no public exploit or Nuclei template. The risk is highest for internet-exposed vLLM endpoints, where an outage would take down production inference. Upgrade to vLLM 0.30.0 or later. Until then, filter or normalize HTTP methods at the reverse proxy and alert on memory growth and an oversized /metrics response.

Sources:NVDEPSSGitHub AdvisoryATLAS

What is the risk?

Medium. The attack is network-reachable, needs no authentication or user interaction, and affects availability only, with no confidentiality or integrity impact. Exploitation is simple: send requests with arbitrary method tokens. The CVSS vector rates complexity high, and exploitation is probably limited by how the frontend is deployed and by proxy filtering. EPSS is low (0.00332), there is no KEV listing, no public exploit and no scanner template. Exposure is greatest for directly internet-facing vLLM servers or those behind proxies that pass arbitrary HTTP methods through. The impact is cumulative: memory is never released until the process restarts.

How does the attack unfold?

Initial Access

Attacker reaches an exposed vLLM endpoint such as /tokenize with no authentication required.

AML.T0049

Exploitation

Attacker sends requests with unique arbitrary HTTP method tokens, each creating permanent Prometheus label sets.

AML.T0049

Resource Exhaustion

Process memory and the /metrics response grow without bound as label cardinality increases.

AML.T0029

Impact

The vLLM service crashes or becomes unresponsive and monitoring breaks, denying inference to dependent applications.

AML.T0029

Initial Access

Attacker reaches an exposed vLLM endpoint such as /tokenize with no authentication required.

AML.T0049

Exploitation

Attacker sends requests with unique arbitrary HTTP method tokens, each creating permanent Prometheus label sets.

AML.T0049

Resource Exhaustion

Process memory and the /metrics response grow without bound as label cardinality increases.

AML.T0029

Impact

The vLLM service crashes or becomes unresponsive and monitoring breaks, denying inference to dependent applications.

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.4%

chance of exploitation in 30 days

Higher than 35% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade vLLM to 0.30.0 or later (see GHSA-5fj9-pfhr-6j48 and PR #56058). 2) Until patched, put a reverse proxy or WAF in front of vLLM that allows only GET, POST and OPTIONS and rejects other method tokens. 3) Do not expose vLLM directly to the internet, and restrict /tokenize and the other inference routes with authentication or network ACLs. 4) Monitor process memory, the number of Prometheus series (cardinality) and the size of the /metrics response, and alert on abnormal growth. 5) Set container memory limits and restart policies to contain the impact. 6) Review proxy and access logs for unusual or random HTTP method values.

How is it classified?

DoSInferenceAPIAML.T0029- Denial of AI Service 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-Procedures to respond to and recover from unknown risks

OWASP LLM Top 10

LLM10-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-105759?

Is CVE-2026-105759 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-105759, increasing the risk of exploitation.

How to fix CVE-2026-105759?

1) Upgrade vLLM to 0.30.0 or later (see GHSA-5fj9-pfhr-6j48 and PR #56058). 2) Until patched, put a reverse proxy or WAF in front of vLLM that allows only GET, POST and OPTIONS and rejects other method tokens. 3) Do not expose vLLM directly to the internet, and restrict /tokenize and the other inference routes with authentication or network ACLs. 4) Monitor process memory, the number of Prometheus series (cardinality) and the size of the /metrics response, and alert on abnormal growth. 5) Set container memory limits and restart policies to contain the impact. 6) Review proxy and access logs for unusual or random HTTP method values.

What systems are affected by CVE-2026-105759?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference endpoints, Kubernetes inference clusters, observability and metrics pipelines.

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

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

What is the AI security impact?

Affected AI Architectures

model servingLLM inference endpointsKubernetes inference clustersobservability and metrics pipelines

MITRE ATLAS Techniques

AML.T0029Denial of AI Service

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

What are the technical details?

Original Advisory

vLLM is an inference and serving engine for large language models. Prior to 0.30.0, the Rust frontend's track_http_metrics middleware records the raw HTTP method token as a Prometheus label for requests reaching registered routes. An unauthenticated attacker can send unique arbitrary method tokens to unguarded routes such as /tokenize, causing Prometheus's Family::get_or_create function to permanently create counter and histogram label sets. Those label sets increase process memory usage and enlarge the /metrics response until the service or monitoring path is exhausted. This issue is fixed in version 0.30.0.

Exploitation Scenario

An attacker finds an internet-exposed vLLM inference endpoint. They send a stream of requests to /tokenize, each with a unique random HTTP method token such as XJ39A or ZZ-0001. The metrics middleware stores every method as a Prometheus label, creating new counter and histogram series that are never evicted. Over minutes or hours, vLLM's memory grows and the /metrics response balloons. The service is eventually OOM-killed or the Prometheus scrape times out, so the organization's LLM-backed applications lose inference and monitoring.

Weaknesses (CWE)

CWE-400Uncontrolled Resource ConsumptionPrimary CWE-400Uncontrolled Resource Consumption

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.