AI Threat AlertvLLM, a widely used LLM inference server, has a flaw in its /v1/responses endpoint where an authenticated caller can supply their own Jinja chat template and bypass the server's trust_request_chat_template policy, exhausting CPU or memory. Impact is availability only (CVSS 6.5, no confidentiality or integrity loss), but exploitation is trivial for anyone holding a valid API key, and vLLM has 94 tracked downstream dependents plus 173 other CVEs, which reflects a large and heavily scrutinized attack surface. No public exploit, Nuclei template, KEV listing or EPSS score exists yet, so this is not an emergency. Upgrade to vLLM 0.32.0 or later (versions 0.16.0 up to 0.32.0 are affected), and until then configure a server-side chat template and restrict /v1/responses access to trusted clients.
What is the risk?
Medium. The attack is network-reachable, low complexity, needs only low privileges (a valid API credential) and no user interaction. Impact is limited to availability (CVSS A:H). Risk rises for multi-tenant or internet-exposed inference gateways where API keys are broadly issued or shared, and for deployments that front vLLM with no per-request resource limits. No known exploitation, public PoC or scanner template as of publication, and EPSS data is unavailable.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | >= 0.16.0, < 0.32.0 | 0.32.0 |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade vLLM to 0.32.0 or later (fix in PR 50300, commit cff08b4). 2) If you cannot patch immediately, configure an explicit server-side chat template so the vulnerable code path is not used, and ensure trust_request_chat_template remains disabled. 3) Restrict /v1/responses to trusted clients via an API gateway, and apply request size limits, rate limiting and per-key quotas. 4) Set container CPU and memory limits with automatic restart and alerting. 5) Detect abuse by monitoring for requests containing chat_template_kwargs with a chat_template field, and for CPU or memory spikes tied to specific API keys.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-115918?
vLLM, a widely used LLM inference server, has a flaw in its /v1/responses endpoint where an authenticated caller can supply their own Jinja chat template and bypass the server's trust_request_chat_template policy, exhausting CPU or memory. Impact is availability only (CVSS 6.5, no confidentiality or integrity loss), but exploitation is trivial for anyone holding a valid API key, and vLLM has 94 tracked downstream dependents plus 173 other CVEs, which reflects a large and heavily scrutinized attack surface. No public exploit, Nuclei template, KEV listing or EPSS score exists yet, so this is not an emergency. Upgrade to vLLM 0.32.0 or later (versions 0.16.0 up to 0.32.0 are affected), and until then configure a server-side chat template and restrict /v1/responses access to trusted clients.
Is CVE-2026-115918 actively exploited?
No confirmed active exploitation of CVE-2026-115918 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-115918?
1) Upgrade vLLM to 0.32.0 or later (fix in PR 50300, commit cff08b4). 2) If you cannot patch immediately, configure an explicit server-side chat template so the vulnerable code path is not used, and ensure trust_request_chat_template remains disabled. 3) Restrict /v1/responses to trusted clients via an API gateway, and apply request size limits, rate limiting and per-key quotas. 4) Set container CPU and memory limits with automatic restart and alerting. 5) Detect abuse by monitoring for requests containing chat_template_kwargs with a chat_template field, and for CPU or memory spikes tied to specific API keys.
What systems are affected by CVE-2026-115918?
This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference APIs, multi-tenant LLM gateways, RAG pipelines, agent frameworks.
What is the CVSS score for CVE-2026-115918?
CVE-2026-115918 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.35%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0034.001Resource-Intensive QueriesAML.T0040AI Model Inference API AccessCompliance Controls Affected
What are the technical details?
Original Advisory
vLLM is an inference and serving engine for large language models. From 0.16.0 until 0.32.0, the /v1/responses endpoint allows an authenticated caller to place an attacker-controlled template in chat_template_kwargs[chat_template] when no server template is configured. ChatParams.get_apply_chat_template_kwargs() preserves that value without enforcing trust_request_chat_template, so the request can bypass the intended trust policy and cause CPU or memory exhaustion through Jinja rendering. This issue is fixed in version 0.32.0.
Exploitation Scenario
An attacker obtains a low-privilege API key for a shared internal or SaaS LLM gateway built on vLLM. They send a request to /v1/responses with chat_template_kwargs[chat_template] set to a Jinja template containing deeply nested loops or massive string multiplication. Because the trust policy is not enforced, the server renders the template, pinning CPU and exhausting memory. Repeating the request a few times takes the inference worker down and denies service to all other tenants and downstream applications.
Weaknesses (CWE)
CWE-400Uncontrolled Resource ConsumptionPrimaryCWE-400Uncontrolled Resource ConsumptionPrimaryCWE-770Allocation of Resources Without Limits or ThrottlingPrimaryCWE-770Allocation of Resources Without Limits or ThrottlingPrimaryCWE-400Uncontrolled Resource ConsumptionCWE-770Allocation of Resources Without Limits or ThrottlingCWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.
- [Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- [Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- github.com/vllm-project/vllm/commit/cff08b461e086523cee8bba5bd3c66d302625134x_refsource_MISC
- github.com/vllm-project/vllm/pull/50300x_refsource_MISC
- github.com/vllm-project/vllm/releases/tag/v0.32.0x_refsource_MISC
- github.com/vllm-project/vllm/security/advisories/GHSA-x567-49g5-p4cfx_refsource_CONFIRM
- github.com/advisories/GHSA-x567-49g5-p4cf
- nvd.nist.gov/vuln/detail/CVE-2026-115918
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm