---
id: "CVE-2026-115911"
kind: "vulnerability"
aliases: ["CVE-2026-115911"]
title: "vLLM: unbounded chat template rendering lets requests hang or exhaust memory"
severity: "medium"
cvss: 6.5
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: []
ecosystems: []
tags: ["ai-tooling", "llm-serving", "python", "self-hosted", "vllm"]
not_affected_if: ["auth-required", "harmony-models", "managed-hosting"]
published_at: "2026-10-26T17:17:18+00:00"
first_seen_at: "2026-10-26T17:31:22+00:00"
updated_at: "2026-10-26T17:33:19+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115911", "first_seen_at": "2026-10-26T17:31:22+00:00"}]
---

# vLLM: unbounded chat template rendering lets requests hang or exhaust memory

vLLM versions from 0.19.0 through 0.32.0 render Jinja chat templates supplied in requests, or shipped by a malicious model repository, with no timeout, output limit or iteration bound. An authenticated caller can send a template that never finishes, blocking /v1/responses and other chat endpoints, or one that expands output until server memory runs out.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed vLLM version with `pip show vllm` or `python -c "import vllm; print(vllm.__version__)"`, and check whether the server was started with `--chat-template`.
- Check whether the service accepts request-supplied chat templates and whether it loads models from untrusted repositories.

## Fix

- Upgrade vLLM to `0.32.0` or later.
- Until upgraded, restrict who can call the API and only load models from trusted repositories.

## Timeline

- 2026-10-26T17:31:22+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-115911

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_