vLLM EUVD-2026-107004

Two concrete prerequisites, both drawn from the description: (1) the vLLM server must be started with trust_remote_code enabled (a non-default, explicitly security-sensitive option), and (2) the attacker must control a revision in the model repository being served, since mm_processor_kwargs.code_revision selects which revision of the dynamic processor code AutoProcessor.from_pretrained imports. Given those, exploitation is remote and unauthenticated against the /tokenize endpoint via a crafted multimodal request. Limiting factors: default deployments (trust_remote_code disabled) are not exploitable, and the attacker needs write/revision control over the served repo - so the realistic risk centers on setups serving attacker-influenceable or third-party model repos with remote code trusted.

This is a genuine high-priority issue, but with a real precondition that tempers raw-score panic. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VC:H/VI:H/VA:H, score 9.2) scores arbitrary code execution reached over the network against the unauthenticated /tokenize endpoint, which is why confidentiality, integrity and availability are all High. The decisive nuance is AT:P (Attack Requirements: Present): per the description, exploitation is only possible when trust_remote_code is enabled AND the attacker can control a revision in the served model repository - this is not a drive-by against any default vLLM install. No EPSS score was provided, and there is no KEV listing and no POC in the supplied data, so exploitation status is 'no public exploit identified at time of analysis' - the 9.2 reflects worst-case impact, not demonstrated widespread exploitation. Signals are therefore consistent rather than conflicting: high impact plus a meaningful enabling condition. One important data caveat: the referenced patch commit diff (570735...) contains only MLA sparse-attention kernel changes and is unrelated to mm_processor_kwargs/code_revision, so the supplied source evidence does not corroborate the described fix - verify the actual remediation in the GHSA advisory.

A vLLM deployment serves a multimodal model with trust_remote_code enabled, and the attacker has push access to a revision of that served model repository. The attacker places malicious dynamic processor code in a revision, then sends an unauthenticated multimodal request to /tokenize with mm_processor_kwargs.code_revision pointing at that revision, causing AutoProcessor.from_pretrained to import and execute the attacker's Python inside the vLLM API process. No public POC was identified in the provided data.