GHSA-h3rc-6mm3-gc2m: Code Injection
Summary
An untrusted multimodal request can set mmprocessorkwargs.coderevision. When vLLM serves a model whose Hugging Face processor uses dynamic automap code and the operator enabled --trust-remote-code, this request value reaches AutoProcessor.frompretrained and selects the Python revision imported by Transformers.
This lets a client replace the operator-reviewed processor module with code from another revision of the same model repository. The operator-selected model/data revision remains pinned; only the executed processor code changes.
Importing a Python module is arbitrary code execution in the vLLM API/renderer process. The PoC below demonstrates this with an import-time filesystem write. It is fully offline and does not require a GPU, model weights, or changes to a real Hub repository.
Affected snapshot
- Repository: vllm-project/vllm - Verified commit: 570735520942b6428ae98f1eb442c6d88adae55e - Verified with Transformers 5.15.0 and 5.16.1 - Affected release range has not been bisected
Affected configuration
The vulnerable path exists when all of the following are true:
1. The served model's processor uses dynamic automap.AutoProcessor code. 2. The operator enabled trustremotecode. 3. The server can fetch the request-selected revision, or it is already cached. 4. The attacker can create or otherwise control a revision in the served model repository. An example is a Hugging Face community pull-request ref when that repository permits them. 5. A multimodal request reaches the processor path.
The default trustremotecode=False configuration is not affected.
Attack surface
mmprocessorkwargs is accepted directly by public request models:
- TokenizeChatRequest.mmprocessorkwargs - ChatCompletionRequest.mmprocessorkwargs
/tokenize is particularly relevant because vLLM's authentication middleware guards only /v1, /v2, /inference, and /cohere prefixes:
- AuthenticationMiddleware
Consequently, /tokenize remains unauthenticated even when --api-key is configured, unless an external proxy protects it. The vLLM Security Guide documents /tokenize as an unprotected endpoint.
Root cause
The request value follows this path:
1. OnlineRenderer.preprocesschat places request mmprocessorkwargs in prompt extras. 2. Multimodal rendering forwards those kwargs into processor construction through MMProcessorInputs and processmultimodalasync. 3. MultiModalConfig.mergemmprocessorkwargs overlays inference values on startup values, so the request wins. 4. cachedgetprocessorwithoutdynamickwargs filters only recognized processor-call keys. coderevision is retained as a processor-construction kwarg. 5. cachedprocessorfromconfig pins revision and trustremotecode, but forwards the remaining kwargs without reserving coderevision. 6. getprocessor calls AutoProcessor.frompretrained(..., revision=revision, trustremotecode=trustremotecode, kwargs). 7. Transformers AutoProcessor.frompretrained uses coderevision to retrieve and import the dynamic module through getclassfromdynamicmodule, then removes it before loading processor data. This is why code comes from the attacker revision while configuration/data remain operator-pinned.
Request-time processor arguments are not separated from processor-construction arguments, and coderevision is not reserved.
Suggested remediation
1. Separate processor-construction arguments from untrusted processor-call arguments. An allowlist of supported request-time preprocessing controls is safest. 2. Reject coderevision and other loader/source controls in request mmprocessorkwargs, and pass modelconfig.coderevision explicitly as the only permitted processor-code revision. 3. Add a regression test proving a request cannot change the loaded module revision while operator pins remain effective. 4. Protect /tokenize with the configured authentication policy as defense in depth.
Expected safe behavior is either a 4xx response for reserved request keys or silently ignoring them before processor construction. Rejection is preferable because it makes attempted misuse visible.
A patch for this was merged here: https://github.com/vllm-project/vllm/pull/58830
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.31.0 - Configuration
Separate processor-construction arguments from untrusted processor-call arguments, reject reserved request keys such as code_revision, and pass model_config.code_revision explicitly as the only permitted processor-code revision.
vLLM multimodal processor request handling mm_processor_kwargs = Reject reserved loader/source controls, including code_revision; allow only supported processor-call controls - Compensating control
Protect the /tokenize endpoint with the configured authentication policy through an external proxy, because it remains unauthenticated even when --api-key is configured.
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments are exposed when vLLM serves a model whose Hugging Face processor uses dynamic auto_map code and the operator has enabled --trust-remote-code. The issue is triggered through an untrusted multimodal request.
What does an attacker need to exploit this?
An attacker needs the ability to submit a multimodal request to the vLLM service. No authentication, user interaction, GPU, model weights, or modification to a real Hugging Face repository is required by the demonstrated proof of concept.
What is the impact of successful exploitation?
The attacker can cause Transformers to import processor Python code from a different revision of the same model repository. Because Python module import can execute arbitrary code, this results in code execution in the vLLM API or renderer process.
Does pinning the model revision prevent exploitation?
No. The operator-selected model and data revision can remain pinned while the request changes the processor code revision that Transformers imports.
What can be done before a patch is available?
Avoid enabling --trust-remote-code for affected model deployments, and do not allow untrusted clients to submit multimodal requests to deployments that require it. The affected configuration depends on both --trust-remote-code and a processor using dynamic auto_map code.