The vulnerability exists in the model loading process of vLLM, where it handles auto_map entries from a model's configuration. The root cause is the failure to check the trust_remote_code flag before loading and executing Python code from a model's repository.
The analysis of the patch 78d13ea9de4b1ce5e4d8a5af9738fea71fb024e5 reveals two key functions involved:
-
_try_resolve_transformers in vllm/model_executor/models/registry.py: This function is responsible for resolving model classes. The patch adds the trust_remote_code parameter to its calls to try_get_class_from_dynamic_module. Before this change, it would trigger the dynamic module loading without any security check, making it a key part of the vulnerability chain.
-
try_get_class_from_dynamic_module in vllm/transformers_utils/dynamic_module.py: This function directly handles the loading of the dynamic module. The patch modifies this function to accept a trust_remote_code parameter and explicitly check it using resolve_trust_remote_code before proceeding. The vulnerable version of this function lacked this check, leading directly to remote code execution if a model's auto_map pointed to malicious code.
An attacker can exploit this by crafting a Hugging Face model repository with a malicious Python file and an auto_map entry in the config.json that points to it. When a vLLM server attempts to load this model, the vulnerable functions execute the malicious code, resulting in remote code execution on the server.