| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| vllm | ≥ 0.16.0, < 0.32.0 | 0.32.0 |
| vllm | ≥ 0.16.0, < 0.32.0 | 0.32.0 |
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.
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.
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.
trust_request_chat_template to OpenAIServingResponses.args.trust_request_chat_template when constructing the Responses serving object.Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phírequest.chat_template_kwargs["chat_template"] before rendering when trust is false.enable_thinking working./v1/responses.Source sweep found the affected shape in:
v0.16.0v0.18.0v0.20.0v0.21.0v0.22.0v0.22.1v0.23.0470229c37efaf69c86e8bc97482b0b1ff7551c65origin/main b3f0a0a0df76dda92ec4b2c9335f77e84adad911Suggested affected range:
>= 0.16.0, <= 0.23.0
This is related to, but distinct from:
GHSA-6fvq-23cw-5628 / CVE-2025-61620GHSA-69j4-grxj-j64p / CVE-2025-62426Those 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.