CVE-2026-115918: 
NixOS vulnerability analysis and mitigation

CVE-2026-115918 is a Denial-of-Service vulnerability in vLLM's /v1/responses endpoint caused by a missing trust gate for request-supplied Jinja chat templates. Affecting vLLM versions >= 0.16.0 and < 0.32.0, an authenticated caller can inject an attacker-controlled Jinja template via chat_template_kwargs[chat_template], bypassing the trust_request_chat_template policy and triggering CPU or memory exhaustion during template rendering. The vulnerability was published on October 26, 2026, and carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). The shared OpenAI frontend enforces a trust_request_chat_template gate on Chat Completions, tokenize, render, and pooling paths, but the /v1/responses serving path (vllm/entrypoints/openai/responses/serving.py) lacked an equivalent check. Specifically, ResponsesRequest.build_chat_params() merges request kwargs, OpenAIServingResponses._effective_chat_template_kwargs() passes them through, and ChatParams.get_apply_chat_template_kwargs() preserves a request-supplied chat_template key when no server template is configured — ultimately passing it to the Jinja renderer without validation. An authenticated attacker can craft a malicious Jinja template (e.g., containing excessive range() calls, string multiplication, or deeply nested loops) to exhaust CPU or memory during rendering (GitHub Advisory, Fix PR).

Successful exploitation causes CPU or memory exhaustion on the vLLM inference server, resulting in denial of service for all chat-style endpoints. Because the rendering occurs synchronously in the serving path, a single malicious request can permanently wedge the server, blocking all subsequent inference requests until the process is restarted. There is no confidentiality or integrity impact; the vulnerability is limited to availability (GitHub Advisory).

Exploitation requires valid authentication credentials to submit /v1/responses requests, limiting the attack surface to authenticated users. No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation as of the publication date. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (Feedly). This vulnerability is related to, but distinct from, prior vLLM Jinja template DoS issues (GHSA-6fvq-23cw-5628 / CVE-2025-61620 and GHSA-69j4-grxj-j64p / CVE-2025-62426) that covered older Chat Completions and tokenize paths (GitHub Advisory).

1. Obtain credentials: Acquire valid API credentials for a vLLM instance running version >= 0.16.0 and < 0.32.0 with no server-side --chat-template configured.
2. Identify the vulnerable endpoint: Confirm the target exposes the /v1/responses endpoint (introduced in vLLM 0.16.0).
3. Craft a malicious Jinja template: Construct a Jinja2 template designed to cause resource exhaustion, such as one with 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 the API: Submit an authenticated POST request to /v1/responses with the malicious template embedded in chat_template_kwargs:

{
  "model": "<model_name>",
  "input": "Hello",
  "chat_template_kwargs": {
    "chat_template": "{% for i in range(10**9) %}{{ 'A' * 10**6 }}{% endfor %}"
  }
}

5. Trigger resource exhaustion: The server's ChatParams.get_apply_chat_template_kwargs() preserves the injected template and passes it to the Jinja renderer without trust validation, causing the rendering thread to consume CPU or memory until the process crashes or becomes unresponsive (GitHub Advisory, Fix PR).

• Network: Authenticated POST requests to /v1/responses containing chat_template_kwargs with a chat_template key, especially with unusual or complex template strings.
• Logs: vLLM server logs showing abnormally long or hung rendering operations; timeout errors referencing VLLM_CHAT_TEMPLATE_RENDER_TIMEOUT (on patched versions); repeated requests to /v1/responses from the same authenticated user.
• Process: Sustained high CPU or memory usage by the vLLM server process without a corresponding increase in legitimate inference load; the vLLM process becoming unresponsive or crashing due to OOM conditions.
• Application: All chat-style endpoints becoming unresponsive following a /v1/responses request containing chat_template_kwargs (Fix PR).

Upgrade to vLLM version 0.32.0 or later, which adds trust_request_chat_template enforcement to OpenAIServingResponses, rejects chat_template_kwargs[chat_template] when the trust flag is disabled, adds static AST validation for dangerous Jinja patterns, and introduces a configurable render timeout via VLLM_CHAT_TEMPLATE_RENDER_TIMEOUT (default 30 seconds) (vLLM Release, Fix Commit). As a workaround for deployments that cannot immediately upgrade, restrict access to the /v1/responses endpoint to trusted users only, or start the server with an explicit --chat-template to prevent the vulnerable code path from being triggered. Additionally, starting the server with --trust-request-chat-template=False (the default) does not fully protect unpatched versions against this specific path, so upgrading is strongly recommended (GitHub Advisory).

The vulnerability was reported by researcher rexpository and coordinated by jperezdealgaba, who also authored the fix. The vLLM maintainer DarkLight1337 reviewed and approved the patch, noting it addressed a gap in the Responses API path missed by earlier fixes. The fix was merged on September 30, 2026, and included in the v0.32.0 release on October 18, 2026, alongside several other security fixes (Fix PR, vLLM Release).