CVE-2026-115918 in vLLM
Summary
by MITRE • 10/26/2026
vLLM is an inference and serving engine for large language models. From 0.16.0 until 0.32.0, the /v1/responses endpoint allows an authenticated caller to place an attacker-controlled template in chat_template_kwargs[chat_template] when no server template is configured. ChatParams.get_apply_chat_template_kwargs() preserves that value without enforcing trust_request_chat_template, so the request can bypass the intended trust policy and cause CPU or memory exhaustion through Jinja rendering. This issue is fixed in version 0.32.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified within vLLM versions ranging from 0.16.0 to 0.32.0 represents a significant security flaw in the handling of chat template parameters for large language model inference services. As an open-source library designed for high-performance LLM serving, vLLM processes user inputs through various endpoints, including /v1/responses. This specific endpoint is intended to handle conversational interactions by applying predefined templates that structure how prompts are formatted before being passed to the underlying model. However, a critical logic error exists in the method ChatParams.get_apply_chat_template_kwargs(), which fails to properly validate or sanitize user-supplied data when no server-side default template is explicitly configured. This oversight allows an authenticated attacker to inject arbitrary Jinja2 templates via the chat_template_kwargs[chat_template] parameter, effectively bypassing intended trust policies that restrict such operations to trusted sources only.
From a technical perspective, the core issue stems from the lack of enforcement for the trust_request_chat_template flag during the processing of request parameters. When an authenticated user submits a request containing a maliciously crafted Jinja template in this specific field, vLLM proceeds to render it without sufficient safeguards against complex or recursive logic. Since Jinja2 is a powerful templating engine used extensively for dynamic content generation, its execution environment can be exploited if given access to dangerous operations or deeply nested structures. The vulnerability does not necessarily lead to remote code execution in the traditional sense but rather facilitates resource exhaustion attacks. By submitting templates that trigger infinite loops, excessive string concatenation, or deep recursion during rendering, an attacker can consume disproportionate amounts of CPU cycles and memory on the server hosting the vLLM instance.
The operational impact of this vulnerability is primarily centered around denial-of-service conditions affecting both availability and performance stability. Because the attack requires authentication, it targets users who have valid credentials to interact with the LLM service. Once exploited, the malicious template causes the Jinja rendering engine to enter a state of high resource consumption. This can lead to server crashes, unresponsiveness for legitimate users, or degradation in inference latency as system resources are drained by the attacker-controlled processes. In cloud-native environments where vLLM is often deployed with limited resource quotas, such exhaustion could trigger automatic scaling events or pod restarts, disrupting service continuity and potentially causing data loss if stateful operations were interrupted mid-execution.
This vulnerability aligns closely with CWE-787 Improper Access Control when considering the bypass of trust policies for template rendering, as well as CWE-400 Uncontrolled Resource Consumption due to the resulting CPU and memory exhaustion. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1496 Resource Hijacking or potentially T1529 System Shutdown/Reboot if the resource exhaustion leads to a crash that requires manual intervention. The attack vector is classified as Network-based with Authentication Required, indicating that while it can be exploited remotely over HTTP/S, the attacker must first obtain valid credentials for the vLLM service instance.
Mitigation strategies focus on immediate patching and configuration hardening. Organizations running affected versions of vLLM should upgrade to version 0.32.0 or later, where this logic error has been corrected by enforcing proper validation checks before template rendering occurs. For environments that cannot immediately update due to compatibility constraints, administrators can implement a workaround by ensuring that a server-side default chat template is always configured and enforced, thereby preventing the code path that allows untrusted user input from being executed in an unrestricted manner. Additionally, deploying web application firewalls or API gateways with rate limiting and request size restrictions can help mitigate the impact of such attacks by detecting anomalous patterns in incoming requests before they reach the vLLM engine. Regular security audits of LLM serving infrastructure should also include testing for template injection vulnerabilities to ensure that dynamic content generation remains isolated from untrusted user inputs.