What happened
Verified against the GitHub advisory (published Oct 21): vLLM lets the client control which revision of a model's dynamic processor code is imported when trust_remote_code is on, and the unauthenticated /tokenize endpoint is the trigger — a single multimodal request runs arbitrary Python in the serving process. The seed's NVD description and the advisory agree on affected range 0.7.3–<0.31.0 and CWE-94 code injection.
Why it matters
Public vLLM serving endpoints are often internet-reachable (OpenAI-compatible /v1 and /tokenize exposed). This turns a remote request into full code execution on the inference host: model-weight theft, provider-API-key theft from env/config, and lateral movement into the GPU cluster.
Attack vector
An unauthenticated attacker sends a multimodal request carrying mm_processor_kwargs.code_revision; vLLM forwards that request-supplied revision to Transformers AutoProcessor.from_pretrained. If trust_remote_code is enabled and the served model repository contains a malicious revision, the request executes arbitrary Python in the vLLM API process via the unauthenticated /tokenize endpoint.
Affected systems
vLLM 0.7.3 – <0.31.0 (fixed in 0.31.0)
Mitigation
Upgrade vLLM to 0.31.0 (0.32.0 recommended for the wider multimodal wave); where possible disable trust_remote_code or restrict processor code to a pinned, reviewed revision. Advisory: GHSA-f623-hjm8-5wg5.