CVE-2026-115918

CVE-2026-115918 is a medium-severity uncontrolled resource consumption vulnerability in vllm (pip), affecting versions >= 0.16.0, < 0.32.0. It is fixed in 0.32.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

vLLM: Responses API bypasses trustrequestchattemplate for chattemplate_kwargs

vLLM's /v1/responses endpoint accepts request-level chat_template_kwargs, but does not apply the --trust-request-chat-template gate that protects Chat Completions, render, tokenize, and pooling paths.

When the server is run with the documented default trust_request_chat_template=False and no explicit --chat-template, a Responses request can pass:

{"chat_template_kwargs": {"chat_template": "<attacker Jinja template>"}}

That key is preserved by ChatParams.get_apply_chat_template_kwargs() and then bound as the chat_template parameter to the shared HF renderer. Prior vLLM advisories establish that request-controlled Jinja chat templates can cause CPU/memory exhaustion. This report covers the current-head Responses sibling path missed by the earlier fixes.

Technical Details

The shared OpenAI frontend has a validation helper that rejects request-supplied chat templates unless the trust flag is enabled. It explicitly checks both top-level chat_template and chat_template_kwargs["chat_template"].

Responses is a separate serving path:

  • vllm/entrypoints/openai/responses/protocol.py exposes chat_template_kwargs.
  • ResponsesRequest.build_chat_params() merges request kwargs.
  • OpenAIServingResponses._effective_chat_template_kwargs() uses those kwargs.
  • ChatParams.get_apply_chat_template_kwargs() preserves a request chat_template key when the server chat template is None.
  • vllm/renderers/hf.py unpacks the result into safe_apply_chat_template.

There is no equivalent trust gate in vllm/entrypoints/openai/responses/serving.py.

Affected Package/Versions

Source sweep found the affected shape in:

  • v0.16.0
  • v0.18.0
  • v0.20.0
  • v0.21.0
  • v0.22.0
  • v0.22.1
  • v0.23.0
  • current checkout 470229c37efaf69c86e8bc97482b0b1ff7551c65
  • current origin/main b3f0a0a0df76dda92ec4b2c9335f77e84adad911

Suggested affected range:

>= 0.16.0, <= 0.23.0

Appendix: Duplicate Research

This is related to, but distinct from:

  • GHSA-6fvq-23cw-5628 / CVE-2025-61620
  • GHSA-69j4-grxj-j64p / CVE-2025-62426

Those advisories establish the security impact of request-controlled Jinja templates and chat_template_kwargs, but they cover older Chat Completions/tokenize implementations. This report covers a current /v1/responses sibling path that still lacks the trust gate.

Local prior submissions this report..029 do not cover this root cause.

This advisory was fixed in MR50300.

Impact

An authenticated caller who can submit /v1/responses requests can supply a request-controlled Jinja chat template despite the trust flag being disabled. The expected fixed behavior is the same as Chat Completions: reject chat_template_kwargs["chat_template"] unless the server was started with --trust-request-chat-template.

Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.

CVE-2026-115918 has a CVSS score of 6.5 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.32.0); upgrading removes the vulnerable code path.

Affected versions

vllm (>= 0.16.0, < 0.32.0)

Security releases

vllm → 0.32.0 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

  • Add trust_request_chat_template to OpenAIServingResponses.
  • Pass args.trust_request_chat_template when constructing the Responses serving object.
  • Reject request.chat_template_kwargs["chat_template"] before rendering when trust is false.
  • Keep ordinary kwargs such as enable_thinking working.
  • Add regression tests for default-deny and opt-in-allow behavior on /v1/responses.

Frequently Asked Questions

  1. What is CVE-2026-115918? CVE-2026-115918 is a medium-severity uncontrolled resource consumption vulnerability in vllm (pip), affecting versions >= 0.16.0, < 0.32.0. It is fixed in 0.32.0. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
  2. How severe is CVE-2026-115918? CVE-2026-115918 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of vllm are affected by CVE-2026-115918? vllm (pip) versions >= 0.16.0, < 0.32.0 is affected.
  4. Is there a fix for CVE-2026-115918? Yes. CVE-2026-115918 is fixed in 0.32.0. Upgrade to this version or later.
  5. Is CVE-2026-115918 exploitable, and should I be worried? Whether CVE-2026-115918 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-115918 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-115918? Upgrade vllm to 0.32.0 or later.

Other vulnerabilities in vllm

CVE-IDSeverityPackage summary
CVE-2026-115917Lowvllm: vLLM: Permissive default CORS origins allow cross-origin requests to the vLLM HTTP serverCVE-2026-115913Mediumvllm: vLLM: Phi-4 multimodal audio encoder materializes and retains full attention matrices: a single max-length audio OOM-crashes the vLLM engineCVE-2026-115914Mediumvllm: vLLM DeepSeek-OCR image processing vulnerable to denial of serviceCVE-2026-115915Highvllm: vLLM: Untrusted EPS inputs can trigger denial of service or Ghostscript RCECVE-2026-115912Highvllm: vLLM: Public multimodal SHM handle forgery reaches worker-side `pickle.loads()` with insecure serialization disabled

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo