CVE-2026-114053: vLLM 0.7.3 before 0.31.0 RCE via mm_processor_kwargs.code_revision
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
Other sources
vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mmprocessorkwargs.coderevision to Transformers AutoProcessor.frompretrained, letting clients select which revision of a model's dynamic processor code is imported when trustremotecode is enabled. An attacker controlling a revision in the served model repository can send a multimodal request to the unauthenticated /tokenize endpoint to execute arbitrary Python in the vLLM API process.
— MITRE
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
Reject code_revision and other loader/source controls in request mm_processor_kwargs, or allowlist only supported request-time preprocessing controls; pass model_config.code_revision explicitly as the permitted processor-code revision.
vLLM request handling mm_processor_kwargs = reject reserved loader/source controls - Compensating control
Protect the /tokenize endpoint with the configured authentication policy through an external proxy, because /tokenize remains unauthenticated even when --api-key is configured.
Event History
Frequently Asked Questions
Which deployments are exposed to exploitation?
vLLM versions from 0.7.3 up to, but not including, 0.31.0 are affected when the served model uses dynamic processor code with trust_remote_code enabled. The exposed request path is the unauthenticated /tokenize endpoint.
What must an attacker be able to do?
An attacker must control a revision in the repository of the model being served. They can then submit a multimodal request containing mm_processor_kwargs.code_revision to cause that revision's processor code to be imported.
What is the impact if exploitation succeeds?
Successful exploitation executes arbitrary Python code in the vLLM API process. This can affect confidentiality, integrity, and availability of that process.
What should be prioritized for mitigation?
Upgrade to vLLM 0.31.0 or later. Until an upgrade is possible, restrict access to the /tokenize endpoint and avoid serving models or model repositories where untrusted parties can control processor-code revisions.