vLLM: request-controlled processor code_revision loads arbitrary remote model code, giving RCE

CVSS 9.2CVE-2026-114053AI/ML frameworks & servingcurated

Impact

A client request can choose which revision of the served model repository's dynamic processor code vLLM imports, so attacker-controlled Python executes inside the vLLM API process. On a GPU node that means code running as the serving user with the GPU devices already mapped in: model weights, API keys and any other tenant data held by that server are readable, and the process can be used as a foothold on the node and its network. The /tokenize endpoint is unauthenticated in a default deployment, so no credentials are needed if the endpoint is reachable. Exploitation requires trust_remote_code to be enabled and the attacker to be able to push or control a revision in the served model repository, which narrows it to fleets serving third-party or user-supplied repos.

Who can reach it

Anyone who can reach the vLLM HTTP endpoint - no authentication needed for /tokenize - provided the server was started with trust_remote_code and the attacker controls a revision in the served model repository.

What to do

Upgrade vLLM to 0.31.0 or later and restart each serving process; a rolling restart per replica is enough, no node reboot. Until then, run without trust_remote_code where possible, serve only model repositories you control, and keep the API endpoint off any network a tenant can reach.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-114053 https://github.com/vllm-project/vllm/security/advisories/GHSA-h3rc-6mm3-gc2m https://github.com/vllm-project/vllm/commit/570735520942b6428ae98f1eb442c6d88adae55e

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.