On this page (7 sections)
A critical vulnerability in vLLM, the Python inference server for large language models, lets request data influence which revision of a model's processor code gets imported. According to the GitHub Advisory Database entry, this can end in arbitrary Python execution inside the vLLM API process when trust_remote_code is enabled.
If you run vLLM versions 0.7.3 up to but not including 0.31.0, especially with a network-reachable API, you should plan an upgrade. One caveat up front: the advisory we are working from was withdrawn as a duplicate, so read the note on that below.
What happened
The advisory describes vLLM taking a client-supplied value, mm_processor_kwargs.code_revision, and passing it to the Transformers AutoProcessor.from_pretrained call. That value selects which revision of a model's dynamic processor code is imported, and it only matters when trust_remote_code is turned on.
The advisory says an attacker who controls a revision in the served model repository can send a multimodal request to the unauthenticated /tokenize endpoint and run arbitrary Python in the vLLM API process.
Why this class of bug is dangerous
Loading a model with trust_remote_code means executing Python that ships with the model repository. That is a deliberate trust decision made by the operator. The weakness here is that a request could steer part of that decision: the revision of the code to import was no longer fixed by the operator but could be chosen by whoever sent the request.
The CVSS v4 vector in the advisory shows network attack vector, low complexity, no privileges, no user interaction, and high impact on confidentiality, integrity and availability of the vulnerable system. The Attack Requirements metric is marked present, which fits the preconditions described: trust_remote_code enabled and an attacker-influenced revision in the served model repository.
Who is affected
- Teams running vLLM from 0.7.3 up to, but not including, 0.31.0.
- Deployments that enable trust_remote_code for multimodal models.
- Servers where the /tokenize endpoint can be reached without authentication, for example an API exposed directly to the internet or a broad internal network.
- Setups that serve models from repositories whose revisions someone other than you can create or change.
Deployments that do not enable trust_remote_code are outside the scenario the advisory describes, though upgrading is still sensible. The advisory does not say whether other configurations are affected, so do not treat the absence of that flag as a guarantee.
How to check your exposure
This command lists the installed vLLM package and its version in the Python environment that runs your server. A version from 0.7.3 up to below 0.31.0 is in the affected range.
pip show vllmIf you run vLLM in a container, run the same command inside the container, or check the image tag you deployed. Then review your launch configuration for the trust_remote_code option and note which model repositories and revisions you serve.
This grep searches a reverse proxy access log for calls to the /tokenize endpoint, so you can see who has been reaching it. Adjust the path to wherever your logs live; any matches from unexpected addresses deserve a closer look.
grep '/tokenize' /var/log/nginx/access.logWhat to do now
0 of 7 done
This command upgrades the vllm package inside the server's Python environment. Restart the service afterward, then confirm with pip show vllm that the version is 0.31.0 or later.
pip install --upgrade 'vllm>=0.31.0'Detection and monitoring afterwards
Inference servers often sit outside the usual web security routine, so make them visible. Keep an inventory of where they run, which ports they expose and who can reach them. Alert on new processes spawned by the API user, unexpected outbound traffic and changes to model files or cached processor code.
If a vLLM endpoint sits behind a public hostname, certificate and DNS changes on that hostname are worth watching; Webforta Monitor covers uptime, certificate and DNS changes. For related issues in AI serving tools, see our write-ups on LMDeploy, LMCache and MLflow.
What we do not know
- Whether the flaw has been exploited in the wild: the source does not say.
- Whether the original advisory, GHSA-h3rc-6mm3-gc2m, differs in scoring or details: we have only reviewed the withdrawn duplicate.
- Any workarounds beyond upgrading: none are given, so the measures above are general hardening, not vendor-confirmed mitigations.
The advisory also references the NVD record, a VulnCheck advisory and a fix commit in the vllm-project/vllm repository.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.