CVE-2026-114053

vLLM requests can select untrusted processor-code revisions

vLLM project · vLLM

First documented disclosure · Review checkpoint

Summary

A multimodal request could replace the operator-reviewed processor code with another repository revision.

Severity and exploitation evidence

Critical · 9.2/10 · CVSS 4.0. Severity source.

Exploitation not established: The reviewed sources do not establish malicious exploitation. A published proof of concept is not evidence of a customer compromise.

Technical severity is not a measure of observed attacks or of risk to your deployment. Attempts, demonstrations, and successful compromise retain the qualifications in the source.

How the weakness works

Request processor arguments were allowed to influence dynamic code loading.

Conditions required

Dynamic processor code, trust_remote_code enabled, and an attacker-controlled revision in the served model repository; the revision must be fetchable or cached.

Potential impact

Arbitrary Python execution in the API or renderer process.

Affected versions and configurations

0.7.3 through versions before 0.31.0, per the CNA.

Fix and mitigation status

0.31.0.

Practical next steps

Upgrade, avoid remote-code trust unless required, and protect auxiliary endpoints such as tokenization with access controls.

Operating lesson

Pin code authority separately from request-controlled preprocessing settings.

Evidence and limits

Default trust_remote_code=False is not affected. October 6 is upstream disclosure; October 21 is CVE publication. The CNA’s 9.2 CVSS 4.0 score reflects conditional exposure; laboratory demonstration is not a reported intrusion.

Sources