CVE-2026-115911: vLLM · DoS via unbounded chat_template Jinja2 rendering exhausts the renderer thread pool
Affects vllmSource GCVE Database
Not known to be exploited · CVSS 6.5 Medium : upgrade to 0.32.0 when convenient.
Data as of 28 Oct 2026, 22:12 UTC
- Patch
- Available – fixed in 0.32.0
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 26 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade vllm to 0.32.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| PyPIvllm | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
### Summary vLLM renders chat templates by passing the resolved Jinja2 source to `tokenizer.apply_chat_template()`, which compiles and `.render()`s it in an `ImmutableSandboxedEnvironment`. The sandbox prevents code-execution escapes but imposes **no wall-clock timeout, no output-size cap, and no nested-loop or binop limit**. The render runs in a `ThreadPoolExecutor` whose `max_workers` defaults to **1**, and CPython worker threads cannot be interrupted. An authenticated API client (or a malicious model repo loaded with `trust_remote_code=False`) can therefore submit a single short template and permanently wedge **all** chat-style endpoints (`/v1/chat/completions`, `/v1/responses`, `/tokenize`, `/pooling`-chat, `/invocations`-chat) for every tenant until the process is restarted. A string-multiplication variant instead OOM-kills the API-server process. Because of a separately-reported (GHSA-jmjw-q4x3-hmc2) gate omission on `/v1/responses`, the remote authenticated attacker vector works in **default `vllm serve` configuration** with no operator opt-in. ### Impact A single authenticated request of <100 bytes permanently denies all chat-style inference (`/v1/chat/completions`, `/v1/responses`, `/tokenize`, `/pooling`-chat, `/invocations`-chat) to **every tenant** of the API-server replica until the operator restarts the process. The string-multiplication variant OOM-kills the process. In a multi-tenant deployment this is a cross-tenant denial-of-service from any one tenant. From the malicious-model angle, a model repo whose `tokenizer_config.json` carries the hostile template wedges every replica that loads it on the first legitimate chat request, with `trust_remote_code=False`. **Preconditions:** any non-harmony model (`model_type != gpt_oss`); `renderer_num_workers` at its default of 1; for the default-config authenticated API attacker vector, `--chat-template` must be unset (the default because most HF models ship their own). **Blast radius:** API-server process, per replica. Engine/worker processes unaffected by the CPU variant (event loop survives); affected by the memory variant (process OOM). **Persistence:** until process restart. Survives client disconnect. This advisory was fixed in [MR50300](https://github.com/vllm-project/vllm/pull/50300).
References
- github.com/vllm-project/vllm/security/advisories/GHSA-542m-9234-8gvf (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-115911 (opens in a new tab)
- github.com/vllm-project/vllm/pull/50300 (opens in a new tab)
- github.com/vllm-project/vllm/commit/cff08b461e086523cee8bba5bd3c66d302625134 (opens in a new tab)
- github.com/vllm-project/vllm (opens in a new tab)
- github.com/vllm-project/vllm/releases/tag/v0.32.0 (opens in a new tab)