CVE-2026-115911: vLLM chat template DoS

Q: Is CVE-2026-115911 actively exploited?

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

Q: How to fix CVE-2026-115911?

1. Upgrade vLLM to 0.32.0 or later (fix in commit cff08b4, PR 50300; see GHSA-542m-9234-8gvf). 2. Until patched, set an explicit server-side --chat-template so request-supplied templates are not used. 3. Restrict API access to trusted principals and enforce per-tenant authentication and rate limits at the gateway. 4. Only load models from vetted repositories, pin revisions, and review tokenizer_config chat templates before deployment. 5. Add watchdog and health checks that restart workers stuck in rendering, and set container memory limits. 6. Detect by monitoring for requests carrying a chat_template parameter, sudden CPU pegging with stalled request queues, and unexpected OOM events on inference pods.

Q: What systems are affected by CVE-2026-115911?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference endpoints, multi-tenant AI gateways, RAG pipelines, agent frameworks.

Q: What is the CVSS score for CVE-2026-115911?

CVE-2026-115911 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.31%.

CISO Take

CVE-2026-115911 is a denial-of-service flaw in vLLM 0.19.0 through versions before 0.32.0. Any authenticated caller can supply a request-level chat template (when no server-side --chat-template is set), or a malicious model repository can ship a template, and the Jinja render has no timeout, output-size limit or iteration bound. Because rendering runs in a single-worker thread pool by default, one non-terminating template can block /v1/responses and other chat-template users even after the request ends, while an output-expanding template can exhaust server memory. Exploitation needs only low privileges over the network, but there is no known public exploit, no Nuclei template, no KEV listing and no EPSS data yet, so urgency is moderate and concentrated in multi-tenant or shared inference endpoints. Upgrade to vLLM 0.32.0, and until then configure a fixed --chat-template server-side and only load models from trusted repositories.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

Medium (CVSS 6.5, availability-only impact). Exploitation is low complexity and needs only low privileges, with no user interaction. Risk is higher for shared or multi-tenant inference gateways, where any API-key holder can take down the service for everyone, and for pipelines that pull third-party models automatically. There is no confidentiality or integrity impact, no evidence of in-the-wild exploitation, and no public PoC at the time of publication. Harmony models are not affected.

How does the attack unfold?

Initial Access

Attacker uses a low-privilege API key on a vLLM server without a fixed --chat-template, or publishes a model repo with a hostile template.

AML.T0040

Exploitation

A crafted Jinja chat template is compiled and rendered by tokenizer.apply_chat_template() with no timeout, size or iteration limit.

AML.T0034.001

Impact

The single render worker hangs or memory is exhausted, blocking /v1/responses and other chat users until restart.

AML.T0029

Initial Access

Attacker uses a low-privilege API key on a vLLM server without a fixed --chat-template, or publishes a model repo with a hostile template.

AML.T0040

Exploitation

A crafted Jinja chat template is compiled and rendered by tokenizer.apply_chat_template() with no timeout, size or iteration limit.

AML.T0034.001

Impact

The single render worker hangs or memory is exhausted, blocking /v1/responses and other chat users until restart.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	>= 0.19.0, < 0.32.0	`0.32.0`
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

6.5 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 24% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

6 steps

Upgrade vLLM to 0.32.0 or later (fix in commit cff08b4, PR 50300; see GHSA-542m-9234-8gvf).
Until patched, set an explicit server-side --chat-template so request-supplied templates are not used.
Restrict API access to trusted principals and enforce per-tenant authentication and rate limits at the gateway.
Only load models from vetted repositories, pin revisions, and review tokenizer_config chat templates before deployment.
Add watchdog and health checks that restart workers stuck in rendering, and set container memory limits.
Detect by monitoring for requests carrying a chat_template parameter, sudden CPU pegging with stalled request queues, and unexpected OOM events on inference pods.

How is it classified?

DoSSupply ChainInferenceAPIFrameworkAML.T0010.003- Model AML.T0029- Denial of AI Service AML.T0034.001- Resource-Intensive Queries AML.T0040- AI Model Inference API Access

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-Response to unknown risks and unexpected events

OWASP LLM Top 10

LLM03-Supply ChainLLM10-Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-115911?

CVE-2026-115911 is a denial-of-service flaw in vLLM 0.19.0 through versions before 0.32.0. Any authenticated caller can supply a request-level chat template (when no server-side --chat-template is set), or a malicious model repository can ship a template, and the Jinja render has no timeout, output-size limit or iteration bound. Because rendering runs in a single-worker thread pool by default, one non-terminating template can block /v1/responses and other chat-template users even after the request ends, while an output-expanding template can exhaust server memory. Exploitation needs only low privileges over the network, but there is no known public exploit, no Nuclei template, no KEV listing and no EPSS data yet, so urgency is moderate and concentrated in multi-tenant or shared inference endpoints. Upgrade to vLLM 0.32.0, and until then configure a fixed --chat-template server-side and only load models from trusted repositories.

Is CVE-2026-115911 actively exploited?

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

How to fix CVE-2026-115911?

1. Upgrade vLLM to 0.32.0 or later (fix in commit cff08b4, PR 50300; see GHSA-542m-9234-8gvf). 2. Until patched, set an explicit server-side --chat-template so request-supplied templates are not used. 3. Restrict API access to trusted principals and enforce per-tenant authentication and rate limits at the gateway. 4. Only load models from vetted repositories, pin revisions, and review tokenizer_config chat templates before deployment. 5. Add watchdog and health checks that restart workers stuck in rendering, and set container memory limits. 6. Detect by monitoring for requests carrying a chat_template parameter, sudden CPU pegging with stalled request queues, and unexpected OOM events on inference pods.

What systems are affected by CVE-2026-115911?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference endpoints, multi-tenant AI gateways, RAG pipelines, agent frameworks.

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

CVE-2026-115911 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.31%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference endpointsmulti-tenant AI gatewaysRAG pipelinesagent frameworks

MITRE ATLAS Techniques

AML.T0010.003Model

AML.T0029Denial of AI Service

AML.T0034.001Resource-Intensive Queries

AML.T0040AI Model Inference API Access

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03, LLM10

What are the technical details?

Original Advisory

vLLM is an inference and serving engine for large language models. From 0.19.0 until 0.32.0, authenticated callers can supply a request chat template when no server-side --chat-template is configured, or a malicious model repository can provide a template that is compiled and rendered by tokenizer.apply_chat_template() without a wall-clock timeout, output-size limit, or iteration bound. Rendering runs in a ThreadPoolExecutor with one worker by default, so a nonterminating render can block /v1/responses and other chat-template users after the request ends, while an output-expanding render can exhaust server memory. Harmony models are not affected because they do not use this Jinja path. This issue is fixed in version 0.32.0.

Exploitation Scenario

An attacker with a low-privilege API key to a shared vLLM endpoint sends a chat completion request containing a custom chat_template with an unbounded Jinja loop. The single rendering worker spins indefinitely, so all other tenants' chat requests and /v1/responses calls hang. Alternatively, the attacker publishes a model repository whose template expands output exponentially; when the victim pulls and serves it, rendering exhausts memory and crashes the inference server.

Weaknesses (CWE)

CWE-400Uncontrolled Resource ConsumptionPrimary CWE-400Uncontrolled Resource ConsumptionPrimary CWE-770Allocation of Resources Without Limits or ThrottlingPrimary CWE-770Allocation of Resources Without Limits or ThrottlingPrimary CWE-834Excessive IterationPrimary CWE-834Excessive IterationPrimary CWE-400Uncontrolled Resource Consumption CWE-770Allocation of Resources Without Limits or Throttling CWE-834Excessive Iteration

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.