CVE-2026-114053

vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code 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.

vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code 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.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-h3rc-6mm3-gc2m. This link is maintained to preserve external references.

Original Description

vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code 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.

Summary

An untrusted multimodal request can set mm_processor_kwargs.code_revision. When vLLM serves a model whose Hugging Face processor uses dynamic auto_map code and the operator enabled --trust-remote-code, this request value reaches AutoProcessor.from_pretrained 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 auto_map.AutoProcessor code.
2. The operator enabled trust_remote_code.
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 trust_remote_code=False configuration is not affected.

Attack surface

mm_processor_kwargs is accepted directly by public request models:

• TokenizeChatRequest.mm_processor_kwargs
• ChatCompletionRequest.mm_processor_kwargs

/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.preprocess_chat places request mm_processor_kwargs in prompt extras.
2. Multimodal rendering forwards those kwargs into processor construction through MMProcessorInputs and _process_multimodal_async.
3. MultiModalConfig.merge_mm_processor_kwargs overlays inference values on startup values, so the request wins. 4.…

vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code 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.

vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code 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.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-h3rc-6mm3-gc2m. This link is maintained to preserve external references.

Original Description

vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code 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.

Summary

An untrusted multimodal request can set mm_processor_kwargs.code_revision. When vLLM serves a model whose Hugging Face processor uses dynamic auto_map code and the operator enabled --trust-remote-code, this request value reaches AutoProcessor.from_pretrained 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 auto_map.AutoProcessor code.
2. The operator enabled trust_remote_code.
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 trust_remote_code=False configuration is not affected.

Attack surface

mm_processor_kwargs is accepted directly by public request models:

• TokenizeChatRequest.mm_processor_kwargs
• ChatCompletionRequest.mm_processor_kwargs

/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.preprocess_chat places request mm_processor_kwargs in prompt extras.
2. Multimodal rendering forwards those kwargs into processor construction through MMProcessorInputs and _process_multimodal_async.
3. MultiModalConfig.merge_mm_processor_kwargs overlays inference values on startup values, so the request wins. 4.…