Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
MEDIUM severity

vLLM: DoS via unbounded chat_template Jinja2 rendering exhausts the renderer thread poolGHSA-542m-9234-8gvf

MEDIUMFix: vllm-project/vllm#50300

GHSA-542m-9234-8gvf is a medium-severity (CVSS 6.5) Uncontrolled Resource Consumption vulnerability in vllm. A fix is available for vllm — see the affected versions and patch details below.

Also known asCVE-2026-115911PYSEC-2026-4344
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 28, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs23th percentile — riskier than 23% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-542m-9234-8gvf by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍vllm

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIvllm≥ 0.19.0&&< 0.32.00.32.0pip install --upgrade 'vllm==0.32.0'

Affected Products

1 product · 1 configurations
Application
vllmvllm
≥ 0.19.0 && < 0.32.0
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vllm, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update vllm to 0.32.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-542m-9234-8gvf is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### 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 an
O3 Security · Impact-Aware SCA

Is GHSA-542m-9234-8gvf in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
vLLM: DoS via unbounded chat_template Jinja2 rendering…