GHSA-x567-49g5-p4cf: Medium severity pip/vllm vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/vllmto a version that resolves this vulnerability.Fixed in 0.32.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch MR50300
Event History
Frequently Asked Questions
Is a default vLLM deployment affected?
Yes. The affected condition is documented default trust_request_chat_template=False with no explicit --chat-template; the Responses path does not enforce the trust gate in that configuration.
What access does an attacker need to trigger the issue?
An attacker needs the ability to submit a request to the /v1/responses endpoint with chat_template_kwargs containing a chat_template value. The supplied template reaches the shared Hugging Face renderer and can cause CPU or memory exhaustion.
Are the other OpenAI serving paths protected by the chat-template trust check?
The validation helper explicitly rejects request-supplied templates, including chat_template_kwargs["chat_template"], for Chat Completions, render, tokenize, and pooling paths unless the trust flag is enabled. The missed enforcement described here is specific to the separate Responses serving path.