CVE-2026-114053: vLLM 0.7.3 before 0.31.0 RCE via mm_processor_kwargs.code_revision

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Published Oct 21, 2026

Updated

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.

Affected Software

1 affected component

vllm vllm>=0.7.3<0.31.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade vLLM to a version that resolves this vulnerability.
Fixed in 0.31.0

Event History

Oct 21, 2026

CVE Published

via MITRE·12:36 AM

Data Sourced

via MITRE·12:36 AM

DescriptionSeverityWeakness

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.

CVE-2026-114053: vLLM 0.7.3 before 0.31.0 RCE via mm_processor_kwargs.code_revision

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are exposed to exploitation?

What must an attacker be able to do?

What is the impact if exploitation succeeds?

What should be prioritized for mitigation?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to exploitation?

What must an attacker be able to do?

What is the impact if exploitation succeeds?

What should be prioritized for mitigation?