CVE-2026-114053 in vLLM
Summary
by MITRE • 10/22/2026
vLLM from 0.7.3 before 0.31.0 forwards the request-supplied mm_processor_kwargs.code_revision to Transformers AutoProcessor.from_pretrained, letting clients select which revision of a model's dynamic processor code is imported when trust_remote_code is enabled. An attacker controlling a revision in the served model repository can send a multimodal request to the unauthenticated /tokenize endpoint to execute arbitrary Python in the vLLM API process.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in versions of vLLM prior to 0.31.0 represents a critical security flaw rooted in improper handling of user-supplied input within multimodal processing pipelines. Specifically, the software fails to validate or restrict the mm_processor_kwargs.code_revision parameter before passing it directly to the Transformers library's AutoProcessor.from_pretrained method. This architectural oversight allows clients with access to the API to influence which revision of a model's dynamic processor code is loaded and executed during inference operations. The risk is significantly amplified when the trust_remote_code configuration option is enabled, as this setting permits the execution of arbitrary Python scripts defined within the model repository rather than relying solely on trusted, static processing logic.
From a technical perspective, the core issue lies in the lack of input sanitization for the code_revision parameter. When an unauthenticated user interacts with the /tokenize endpoint or similar multimodal interfaces, they can supply a specific revision identifier that points to a maliciously crafted model repository hosted on platforms such as Hugging Face Hub. Upon receiving this request, vLLM retrieves and executes the Python code associated with that revision without verifying its integrity or origin beyond basic authentication checks for the API itself. This mechanism effectively bypasses standard security boundaries because it treats user-controlled input as trusted configuration data, leading to a classic case of insecure deserialization or remote code execution through dynamic import mechanisms.
The operational impact of this vulnerability is severe, allowing an attacker with network access to achieve arbitrary Python code execution within the context of the vLLM API process. This level of compromise grants full control over the underlying system where the inference server resides. Attackers can leverage this capability to exfiltrate sensitive data processed by the model, such as private documents or personal information contained in multimodal inputs. Furthermore, they may pivot from the compromised application layer to attack other systems within the internal network, install persistent backdoors, or disrupt service availability through resource exhaustion attacks initiated via malicious processor code.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code and is categorized under ATT&CK technique T1059 Command and Scripting Interpreter for lateral movement and execution capabilities. The exploitation vector corresponds to remote unauthenticated access, highlighting the necessity for strict input validation in all API endpoints that interact with external model repositories. To mitigate this risk, organizations must ensure they are running vLLM version 0.31.0 or later where these checks have been implemented. Additionally, administrators should disable trust_remote_code unless absolutely necessary and restrict network access to inference endpoints using firewalls or authentication gateways. Regular auditing of dependencies and adherence to secure coding practices that treat all external inputs as untrusted are essential steps in preventing similar exploitation scenarios in machine learning infrastructure.