CVE-2026-115911 in vLLM
Summary
by MITRE • 10/26/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified within vLLM versions ranging from 0.19.0 to 0.32.0 represents a significant security flaw related to the handling of chat templates during inference and serving operations for large language models. This issue stems from insufficient input validation and resource management controls when processing user-supplied or repository-provided Jinja-based chat templates. Specifically, if the server is not explicitly configured with a --chat-template flag, authenticated users are permitted to supply their own request-level chat template. Additionally, malicious model repositories can embed templates that trigger unsafe rendering behaviors. The core technical flaw lies in the execution of tokenizer.apply_chat_template(), which processes these Jinja templates without implementing critical safeguards such as wall-clock timeouts, output size limits, or iteration bounds. This lack of constraints allows for potentially infinite loops or unbounded memory expansion during template rendering.
From a technical perspective, vLLM utilizes a ThreadPoolExecutor with only one worker thread by default to handle concurrent tasks. When a non-terminating render is triggered due to the absence of an iteration bound or timeout, it occupies this single worker indefinitely. Consequently, subsequent requests targeting /v1/responses and other endpoints that rely on chat-template rendering are blocked until the malicious request completes or times out externally. This creates a direct path for Denial of Service attacks against authenticated users. Furthermore, if the template logic results in an output-expanding render, where each iteration generates significantly more data than it consumes, the server's memory usage can grow uncontrollably. This unbounded resource consumption can lead to Out-Of-Memory conditions, causing the vLLM instance to crash or become unstable, thereby disrupting service availability for all connected clients.
The operational impact of this vulnerability is severe, particularly in multi-tenant environments where authenticated users have the ability to define custom inference parameters. An attacker with valid credentials could exploit this flaw to exhaust server resources, effectively taking down the LLM serving infrastructure. In scenarios involving untrusted model repositories, even non-authenticated interactions might be at risk if the repository's embedded template is automatically processed without adequate sandboxing or limits. The vulnerability aligns with CWE-787: Out-of-bounds Write and CWE-400: Uncontrolled Resource Consumption in terms of resource exhaustion, while also reflecting aspects of CWE-611: Improper Restriction of XML External Entity References if the Jinja rendering is viewed through a lens of untrusted template processing. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1499: Endpoint Denial of Service and potentially T1053: Scheduled Task/Job as it involves manipulating system resources to degrade performance or availability.
It is important to note that Harmony models are not affected by this specific vulnerability because their architecture does not utilize the Jinja-based template rendering path susceptible to these infinite loop or memory exhaustion conditions. The issue was addressed in version 0.32.0 of vLLM, which introduces necessary safeguards such as timeouts and limits on output size during template application. To mitigate risks for users operating within the vulnerable range, it is recommended to upgrade immediately to version 0.32.0 or later. For environments that cannot yet upgrade, administrators should ensure that a server-side --chat-template is explicitly configured to prevent authenticated callers from overriding templates with untrusted inputs. Additionally, implementing network-level timeouts and monitoring memory usage patterns can provide partial mitigation against resource exhaustion attacks until the software patch is applied.