PYSEC-2026-4349: vLLM: Responses API bypasses trust_request_chat_template for chat_template_kwargs

Summary

vLLM's /v1/responses endpoint accepts request-level chattemplatekwargs, 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 trustrequestchattemplate=False and no explicit --chat-template, a Responses request can pass:

json {"chattemplatekwargs": {"chattemplate": "<attacker Jinja template>"}}

That key is preserved by ChatParams.getapplychattemplatekwargs() and then bound as the chattemplate 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 chattemplate and chattemplatekwargs["chattemplate"].

Responses is a separate serving path:

- vllm/entrypoints/openai/responses/protocol.py exposes chattemplatekwargs. - ResponsesRequest.buildchatparams() merges request kwargs. - OpenAIServingResponses.effectivechattemplatekwargs() uses those kwargs. - ChatParams.getapplychattemplatekwargs() preserves a request chattemplate key when the server chat template is None. - vllm/renderers/hf.py unpacks the result into safeapplychattemplate.

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

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 chattemplatekwargs["chattemplate"] unless the server was started with --trust-request-chat-template.

Suggested Fix

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

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:

text = 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 chattemplatekwargs, 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.