CVE-2026-115918: 
NixOS Análisis y mitigación de vulnerabilidades

CVE-2026-115918 is a Denial of Service vulnerability in vLLM, an inference and serving engine for large language models, caused by improper trust enforcement for attacker-controlled Jinja2 chat templates submitted via the /v1/responses API endpoint. Affecting versions 0.16.0 through 0.31.x (fixed in 0.32.0), an authenticated caller can inject a malicious Jinja template through chat_template_kwargs[chat_template] when no server-side template is configured, bypassing the trust_request_chat_template policy and causing CPU or memory exhaustion. The vulnerability was published on October 26, 2026, with a fix released in vLLM v0.32.0. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified under CWE-400 (Uncontrolled Resource Consumption), CWE-770 (Allocation of Resources Without Limits or Throttling), and CWE-94 (Improper Control of Code Generation). The /v1/responses endpoint in vllm/entrypoints/openai/responses/serving.py exposes chat_template_kwargs, and ChatParams.get_apply_chat_template_kwargs() preserves a request-supplied chat_template key when the server has no configured template — without invoking the trust_request_chat_template gate that protects other endpoints (Chat Completions, tokenize, pooling). The preserved template is then passed to vllm/renderers/hf.py's safe_apply_chat_template, where unbounded Jinja2 rendering (e.g., infinite loops, exponential string expansion) can exhaust CPU and memory. The fix adds a validate_chat_template call in OpenAIServingResponses._create_responses() and, in the Rust frontend, enables minijinja's fuel feature capping execution at 500,000 instructions per render (GitHub Advisory, Fix PR).

Successful exploitation causes CPU and memory exhaustion on the vLLM server, rendering the inference service unavailable to all users — a complete availability impact with no confidentiality or integrity compromise. Because vLLM serves as a shared inference backend for large language models, a single malicious authenticated request can permanently wedge all chat-style endpoints until the process is restarted. There is no evidence of lateral movement potential or data exfiltration risk associated with this vulnerability (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The NVD SSVC assessment rates exploitation as "none" and the attack as non-automatable, reflecting the requirement for authenticated access. The EPSS score is approximately 0.32%, indicating low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Feedly).

1. Obtain authenticated access: Acquire a valid API key or credentials for a vLLM instance running versions 0.16.0–0.31.x with no server-side --chat-template configured and --trust-request-chat-template not explicitly enabled.
2. Identify the vulnerable endpoint: Confirm the target exposes the /v1/responses endpoint (introduced in vLLM 0.16.0) by sending a benign test request.
3. Craft a resource-exhausting Jinja2 template: Construct a malicious Jinja2 template designed to cause CPU or memory exhaustion, such as one containing deeply nested loops, excessive range() calls, or exponential string multiplication (e.g., {% for i in range(10**9) %}{{ 'A' * 10**6 }}{% endfor %}).
4. Inject the template via chat_template_kwargs: Submit a POST request to /v1/responses with the malicious template embedded in the chat_template_kwargs field: {"chat_template_kwargs": {"chat_template": "<malicious_template>"}}.
5. Trigger resource exhaustion: The server's ChatParams.get_apply_chat_template_kwargs() preserves the attacker-supplied template and passes it to the Jinja renderer without trust validation, causing the server process to consume unbounded CPU and memory until it becomes unresponsive or crashes (GitHub Advisory, Fix PR).

• Network: Authenticated POST requests to /v1/responses containing chat_template_kwargs with a chat_template key, especially from clients that do not normally supply custom templates; repeated or sustained requests to this endpoint from a single source.
• Logs: vLLM access logs showing /v1/responses requests with large or unusual chat_template_kwargs payloads; timeout errors or warnings referencing VLLM_CHAT_TEMPLATE_RENDER_TIMEOUT in server logs (on patched versions); log entries such as "Chat template render timed out" or "executor pool replaced".
• Process: Sustained high CPU utilization by the vLLM Python process without a corresponding increase in legitimate inference throughput; memory usage growing unboundedly during or after a /v1/responses request.
• System: Out-of-memory (OOM) kills of the vLLM process; system-level alerts for CPU saturation correlated with API activity on the /v1/responses endpoint (Fix PR, GitHub Advisory).

The primary remediation is to upgrade vLLM to version 0.32.0 or later, which adds trust validation to the /v1/responses endpoint, static AST validation of templates, a configurable render timeout (VLLM_CHAT_TEMPLATE_RENDER_TIMEOUT, default 30 seconds), and a 500,000-instruction fuel cap in the Rust frontend (vLLM v0.32.0 Release, Fix Commit). For deployments that cannot immediately upgrade, restrict network access to the /v1/responses endpoint to only trusted, known-good clients, implement API request rate limiting, and monitor server CPU and memory utilization for anomalous spikes. Configuring a server-side --chat-template also prevents the vulnerable code path from being triggered, as the attacker-supplied template is only used when no server template is set (GitHub Advisory).

The vulnerability was reported by researcher rexpository and coordinated by jperezdealgaba, who also authored the fix. The GitHub advisory notes this is related to but distinct from prior vLLM Jinja template advisories (GHSA-6fvq-23cw-5628 / CVE-2025-61620 and GHSA-69j4-grxj-j64p / CVE-2025-62426), which covered older Chat Completions and tokenize paths. Red Hat tracked the issue via Bugzilla and assigned it medium severity. Community discussion on the fix PR highlighted the complexity of safely handling user-supplied templates in AI serving infrastructure (GitHub Advisory, Fix PR, Red Hat Bugzilla).