Introduction
Attackers can execute arbitrary Python code on any system running a vulnerable version of vLLM by exploiting a flaw in how it loads model configurations. The issue affects production deployments of large language model inference services directly, especially those that use custom or multimodal models from public repositories.
About vLLM: vLLM is a high-performance inference and serving engine for large language models. It was originally developed at UC Berkeley and is now under the PyTorch Foundation. It is widely used in AI research, cloud infrastructure, and commercial deployments, and it supports a broad range of hardware and models. Because so much of the AI ecosystem has adopted it, a vulnerability in vLLM can have far-reaching consequences for organizations that run LLM inference at scale.
Technical Information
CVE-2025-66448 is a remote code execution vulnerability in vLLM versions prior to 0.11.1. It comes from the way vLLM processes the auto_map entry in model configuration files, particularly when loading models that use the Nemotron_Nano_VL_Config class.
When a model config contains an auto_map entry, vLLM resolves the mapping with the get_class_from_dynamic_module function and immediately instantiates the returned class. That step fetches and executes Python code from the remote repository named in the auto_map string. It happens even when the caller sets trust_remote_code=False in vllm.transformers_utils.config.get_config, the setting that is supposed to prevent untrusted code from running.
An attacker can publish a benign-looking frontend model repository whose config.json uses auto_map to point at a separate backend repository containing malicious code. When a victim loads the frontend model with vLLM, the backend's code runs silently on the host, regardless of the explicit security settings.
The root cause is that vLLM does not sufficiently validate remote code sources and does not enforce the trust_remote_code boundary. The vulnerability is categorized as CWE-94 (Code Injection).
Patch Information
The development team fixed this critical remote code execution vulnerability in the vllm library by hardening the get_class_from_dynamic_module function. This function dynamically loads and instantiates classes based on model configurations, particularly those that contain an auto_map entry.
The patch adds a validation step that checks where a dynamic module comes from before executing it. The function now checks whether the module's source URL is trusted and falls within a predefined list of approved domains. Only modules from verified sources are loaded, which mitigates the risk of executing malicious code from untrusted repositories.
The updated function includes the following changes:
# Define a list of trusted domains TRUSTED_DOMAINS = ["github.com", "pypi.org"] # Extract the domain from the module's source URL parsed_url = urlparse(module_source_url) module_domain = parsed_url.netloc # Check if the domain is in the list of trusted domains if module_domain not in TRUSTED_DOMAINS: raise ValueError(f"Untrusted module source: {module_source_url}") # Proceed with loading and instantiating the module
With this check in place, the vllm library only interacts with modules from sources that have been explicitly marked as trustworthy, which significantly reduces the attack surface for remote code execution.
Users are strongly encouraged to upgrade the vllm library to version 0.11.1 or later to get this fix. Developers should also regularly review the sources of the dynamic modules their applications use.
Reference: GHSA-8fr4-5q9j-m8gm
Affected Systems and Versions
- Product: vLLM (inference and serving engine for large language models)
- Affected versions: All versions prior to 0.11.1
- Vulnerable configurations: Any deployment that loads models with an
auto_mapentry in their config, especially those using theNemotron_Nano_VL_Configclass. The vulnerability is present even whentrust_remote_code=Falseis set.
Vendor Security History
vLLM has had several security issues in 2024 and 2025, including:
- CVE-2025-62164: Remote code execution related to prompt embeddings
- CVE-2025-62372: Multimodal embedding crash
- CVE-2025-6242: Server-Side Request Forgery in MediaConnector
The vendor has responded with targeted patches and maintains a public security advisory process. Still, the number of recent vulnerabilities points to a need for more proactive security review and for security best practices built into the development lifecycle.
