vLLM: Responses API bypasses trust_request_chat_template for chat_template_kwargs

Summary

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.

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.

Suggested Fix

• 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.

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.