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 .