EUVD-2026-109996
GHSA-542m-9234-8gvf
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid API credential
-
DeliverySubmit request with crafted Jinja2 chat_template
-
ExploitRender loops/expands with no fuel or timeout
-
ExecutionWedge single-worker thread pool or OOM process
-
ImpactCross-tenant denial of all chat endpoints until restart
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a non-harmony model (model_type != gpt_oss; Harmony/gpt_oss models skip this Jinja path entirely) and renderer_num_workers at its default of 1. Two trigger vectors: (1) an authenticated API caller supplies a per-request chat_template, which works in default 'vllm serve' config when --chat-template is unset (the common case, since most HF models ship their own template) and is reachable via /v1/responses due to the related GHSA-jmjw-q4x3-hmc2 gate omission; or (2) a malicious model repository whose tokenizer_config.json carries the hostile template, which wedges any replica loading it on the first legitimate chat request even with trust_remote_code=False. Limiting factors: the attacker needs a valid API credential (PR:L); impact is confined to the API-server process per replica (engine/worker processes survive the CPU variant); effect persists until operator restart and survives client disconnect; Harmony models and deployments with an operator-set --chat-template reduce the authenticated-request vector. |
| Impact | Severity signals are moderate and internally consistent: the supplied CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 6.5) describes a network-reachable, low-complexity, authenticated attack with availability-only impact and no scope change - a classic resource-exhaustion DoS (CWE-400, with CWE-770 and CWE-834 added by the vendor advisory). The vuln.today Decision label is this_month, not act_now or emergency, and the vulnerability is not listed in CISA KEV; no EPSS score was provided in the input, so real-world exploitation probability cannot be quantified from the available data - state that gap explicitly rather than assume it is low. There is no PoC/exploit flag in the input (only vendor advisory, PR, commit, and release references), so this is no public exploit identified at time of analysis. The practical risk is higher than the mid-range score suggests for multi-tenant operators: per the GHSA advisory a single sub-100-byte authenticated request permanently wedges all chat-style endpoints for every tenant of a replica until restart (CPU variant) or OOM-kills the API-server process (string-multiplication variant), and a related gate omission (GHSA-jmjw-q4x3-hmc2) on /v1/responses makes the authenticated-attacker vector work in a default 'vllm serve' configuration. The main limiter is PR:L - the attacker must hold a valid API credential - so single-tenant deployments with trusted callers face lower real risk than shared multi-tenant services. This is a genuine availability priority for multi-tenant vLLM operators, not a purely theoretical high-CVSS issue, though the authentication requirement and availability-only impact keep it below critical. |
| Exploit ScenarioDerived | An authenticated API client of a multi-tenant vLLM deployment submits a single short (<100 byte) chat request carrying a malicious Jinja2 chat_template; the template renders in an unbounded loop with no timeout, wedging the single-worker render thread pool and denying all chat-style endpoints to every tenant until the process is restarted, or a string-multiplication variant exhausts memory and OOM-kills the API server. Because of a separate gate omission on /v1/responses, this works in a default 'vllm serve' configuration where --chat-template is unset. CVSS AC:L and PR:L mean the attack is low-complexity and needs only a valid API credential; no public exploit code is identified in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 26, 2026
Denial of service in vLLM 0.19.0 through 0.31.x lets a caller who holds a valid API credential hand the server a hostile Jinja2 chat template - either directly in the request when the operator has not set --chat-template, or indirectly through a model repository whose tokenizer_config.json carries one - and hang every chat-style endpoint on that API-server replica until the process is restarted. The render runs inside a sandboxed Jinja environment with no wall-clock timeout, no output-size cap and no loop or binop bound, on a render pool that defaults to a single non-interruptible worker, so a tiny non-terminating template wedges /v1/chat/completions, /v1/responses, /tokenize and the chat pooling/invocations paths for all tenants, while a string-multiplication variant instead OOM-kills the process. Impact is availability-only across tenants of one replica (CVSS:3.1 6.5, PR:L), Harmony/gpt_oss models skip the affected Jinja path, and no public exploit code was identified at time of analysis; the vendor shipped a fix in 0.32.0.
RemediationAI
Vendor-released patch: vLLM 0.32.0 (https://github.com/vllm-project/vllm/releases/tag/v0.32.0, fixing commit cff08b461e086523cee8bba5bd3c66d302625134 via https://github.com/vllm-project/vllm/pull/50300, described in GHSA-542m-9234-8gvf); upgrade every API-server replica to 0.32.0 or later, which introduces a 500,000-unit render fuel budget, moves rendering off the shared async runtime, and lets a wedged render worker be swapped out. Where an immediate upgrade is not possible, the vendor-documented limiting factor is to configure --chat-template explicitly on the server so callers cannot supply their own per-request template - this removes the authenticated API vector but does nothing against a malicious model repository whose tokenizer_config.json carries the hostile template, so only load tokenizer configs from reviewed sources; note also that such a repository wedges replicas on the first legitimate chat request even with trust_remote_code=False. Recovery from an already wedged replica requires a process restart, since the CPU variant blocks all chat-style endpoints (including /v1/responses, reachable via the GHSA-jmjw-q4x3-hmc2 gate omission) until then, while engine and worker processes survive the CPU variant but are lost to the OOM-killing string-multiplication variant. Because the only complete fix is the 0.32.0 upgrade and no vendor-supplied interim control addresses the memory variant, restrict API credentials to trusted tenants and monitor the renderer for stalled chat endpoints in the interim.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
vLLM resolves a model's chat template to Jinja2 source and hands it to tokenizer.apply_chat_template(), which compiles and .render()s it inside Hugging Face's ImmutableSandboxedEnvironment. That sandbox blocks code-execution escapes but imposes no wall-clock timeout, no output-size limit and no nested-loop or binop budget, so an attacker-controlled template is effectively unbounded work driven by a sub-100-byte request. The render is dispatched onto a ThreadPoolExecutor whose max_workers is governed by renderer_num_workers and defaults to 1; CPython worker threads cannot be interrupted, so one non-terminating render blocks all subsequent chat-template renders and the effect survives client disconnect, persisting until the process is restarted. This is CWE-400 (uncontrolled resource consumption), with the vendor advisory also tagging CWE-770 (allocation without limits) and CWE-834 (excessive iteration). Reachability in a default 'vllm serve' deployment depends on --chat-template being unset, which is the common case because most HF models ship their own template; the /v1/responses endpoint is reachable via a separately reported gate omission (GHSA-jmjw-q4x3-hmc2). The fix (PR 50300) adds an instruction fuel budget of 500,000 to the Rust minijinja renderer, offloads rendering through tokio spawn_blocking so it no longer stalls the shared runtime, and introduces a swappable executor in the Python renderer that recycles a wedged worker while keeping make_async wrappers and tokenize/decode paths alive.
Know when Vllm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Network-reachable, low-complexity render abuse requiring a valid API credential (PR:L); availability-only impact (A:H) with no confidentiality/integrity effect and no cross-process scope change.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
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.
Blast Radius
ecosystem impact- 1 pypi packages depend on vllm (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 0.19.0.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated critical severity (CVSS 10.0
vllm-project vllm version v0.6.2 contains a vulnerability in the MessageQueue.dequeue() API function. Rated critical sev
Information exposure in vLLM inference engine versions 0.8.3 to before 0.14.1. Invalid image requests to the multimodal
Timing-based API key recovery in vLLM before 0.11.0rc2 can let remote attackers bypass bearer-token authentication on de
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated high severity (CVSS 7.5), th
Denial of service in the vLLM LLM inference server (all versions prior to 0.24.0) allows a remote client to crash the sh
vLLM before version 0.14.1 contains a server-side request forgery vulnerability in the MediaConnector class where incons
Out-of-memory worker crashes in vLLM can be induced by a single small compressed audio payload submitted to the /v1/chat
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Rated medium severity (CVSS 6.5),
GPU memory exhaustion in vLLM versions prior to 0.28.0 lets an attacker with low-privileged API access (PR:L in the CVSS
Multimodal inference requests to vLLM deployments running versions prior to 0.28.0 can trigger a process-level assertion
Uncontrolled resource consumption in vLLM's OpenAI-compatible completions endpoint allows any authenticated API client t
Exploit-DB