vLLM Responses endpoint accepted chat-template kwargs despite a disabled trust flag

vLLM applied trust-request-chat-template validation to Chat endpoints but failed to apply the same rejection to nested template kwargs arriving through its Responses API.

The affected service must expose the OpenAI-compatible Responses route and pass caller-controlled chat_template_kwargs while request templates are disabled in configuration. A client could get a forbidden template evaluated and potentially combine the bypass with the separate Jinja CPU exhaustion mechanism.

Authentication was not bypassed; this is a route-policy mismatch, not a distinct demonstrated arbitrary code execution. Upgrade vLLM to 0.32.0 and enforce the same template trust decision at a shared request-normalization boundary for every endpoint.

Evidence interpretation and control boundary. The policy mismatch is between two OpenAI-compatible request routes. The Chat endpoint enforced a prohibition on caller-provided templates, while a nested chat_template_kwargs field in Responses bypassed that check and reached rendering. It can combine with the separate unbounded-Jinja workload, but this bypass itself does not prove any independent shell execution or authentication failure. Normalize both routes into one enforced template-authority decision.