<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-30T15:33:27.332180+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-115918</id>
    <title>CVE-2026-115918 — vLLM: Responses API bypasses trust_request_chat_template for chat_template_kwargs</title>
    <updated>2026-10-30T15:33:27.333425+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> vllm-project vllm</p>
<p>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.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-115918"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-x567-49g5-p4cf</id>
    <title>GHSA-x567-49g5-p4cf — vLLM: Responses API bypasses trust_request_chat_template for chat_template_kwargs</title>
    <updated>2026-10-30T15:33:27.333496+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: vllm</p>
<p>## Summary</p>
<p>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.</p>
<p>When the server is run with the documented default `trust_request_chat_template=False` and no explicit `--chat-template`, a Responses request can pass:</p>
<p>```json
{"chat_template_kwargs": {"chat_template": "&lt;attacker Jinja template&gt;"}}
```</p>
<p>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.</p>
<p>## Technical Details</p>
<p>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"]`.</p>
<p>Responses is a separate serving path:</p>
<p>- `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 `s…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-x567-49g5-p4cf"/>
  </entry>
</feed>
