CVE-2025-66448: 
NixOS vulnerability analysis and mitigation

CVE-2025-66448 is a remote code execution (RCE) vulnerability in vLLM, an inference and serving engine for large language models (LLMs), affecting all versions prior to 0.11.1. The flaw resides in the Nemotron_Nano_VL_Config class within vllm/transformers_utils/configs/nemotron_vl.py, which fetches and executes arbitrary Python code from remote Hugging Face repositories via auto_map entries — critically, even when trust_remote_code=False is explicitly set by the caller. The vulnerability was disclosed on December 1, 2025, with a patch released in vLLM 0.11.1 (Github Advisory). CVSS v3.1 scores differ by source: NVD assigns 8.8 (High) while the CNA (GitHub) assigns 7.1 (High) (Github Advisory).

The root cause (CWE-94: Improper Control of Generation of Code) lies in the Nemotron_Nano_VL_Config.__init__ method, which unconditionally calls get_class_from_dynamic_module(*vision_config["auto_map"]["AutoConfig"].split("--")[::-1]) to resolve and instantiate a class from a remote repository specified in the model's config.json (Github Advisory). The get_class_from_dynamic_module() function is capable of fetching and importing Python code from any Hugging Face repository referenced in the auto_map string, and this code path does not check or enforce the trust_remote_code flag passed to vllm.transformers_utils.config.get_config (Github Advisory). An attacker can craft a benign-looking "frontend" model repository whose config.json contains an auto_map entry pointing to a separate malicious "backend" repository; when vLLM loads the frontend model config, it silently fetches and executes the backend's Python code on the victim host. The fix, implemented in PR #28126, removes the vulnerable Nemotron_Nano_VL_Config class entirely and replaces the local config copy with the upstream Transformers library version (vllm PR #28126).

Successful exploitation results in arbitrary code execution on the host running vLLM, with full confidentiality, integrity, and availability impact. Any application, service, CI/CD pipeline, or developer machine using vLLM's transformer utilities to load model configurations is potentially affected, including production inference servers and automated model evaluation workflows (Github Advisory). A successful attacker could steal model weights, exfiltrate credentials or sensitive data, install persistent backdoors, disrupt service availability, or pivot laterally to other systems on the network (Feedly).

As of the disclosure date, there is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.045% (14th percentile), indicating a low near-term exploitation probability (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. Despite the low EPSS, the attack is conceptually straightforward — requiring only two Hugging Face repositories and minimal user interaction (loading a model) — making it a plausible supply-chain attack vector against AI/ML infrastructure.

1. Create a malicious backend repository: Publish a Hugging Face repository containing a Python module (e.g., configuration_vision.py) with arbitrary malicious code in its class definition or module-level execution (e.g., reverse shell, credential exfiltration).
2. Create a benign-looking frontend repository: Publish a second Hugging Face repository that appears to be a legitimate model. In its config.json, include a vision_config section with an auto_map entry pointing to the malicious backend repository, e.g., "auto_map": {"AutoConfig": "malicious-user/malicious-repo--configuration_vision.MaliciousVisionConfig"}.
3. Induce the victim to load the frontend model: Social-engineer or otherwise cause a user or automated system running a vulnerable vLLM version (< 0.11.1) to load the frontend model, e.g., via vllm.LLM(model="attacker/frontend-model") or any API call that triggers config loading.
4. Trigger automatic code execution: When vLLM's Nemotron_Nano_VL_Config.__init__ processes the vision_config, it calls get_class_from_dynamic_module() with the attacker-controlled auto_map string, fetching and importing the malicious Python module from the backend repository — bypassing the trust_remote_code=False guard.
5. Achieve arbitrary code execution: The malicious code runs in the context of the vLLM process on the victim host, enabling reverse shell establishment, data exfiltration, persistence mechanisms, or lateral movement (Github Advisory, vllm PR #28126).

• Network: Unexpected outbound HTTPS connections from the vLLM process to huggingface.co or cdn-lfs.huggingface.co for repositories not matching the intended model being loaded; outbound connections to unknown external IPs (reverse shell, C2) originating from the vLLM Python process.
• File System: Newly downloaded Python files in the Hugging Face cache directory (typically ~/.cache/huggingface/hub/) from unexpected or unknown repositories; unexpected scripts, cron jobs, or SSH keys created by the vLLM service account.
• Logs: vLLM or Python logs showing get_class_from_dynamic_module calls referencing unexpected or unknown Hugging Face repositories; HTTP requests to Hugging Face for model files from repositories not in the approved model list.
• Process: Unusual child processes spawned by the vLLM Python process (e.g., bash, sh, curl, wget, python, nc) that are not part of normal inference operations; unexpected network connections from the vLLM process to non-Hugging Face endpoints.

The primary remediation is to upgrade vLLM to version 0.11.1 or later, which removes the vulnerable Nemotron_Nano_VL_Config class entirely (Github Advisory, vllm PR #28126). Red Hat has also issued multiple errata (RHSA-2025:23078, RHSA-2025:23209, RHSA-2025:23205, RHSA-2025:23449) for affected Red Hat products incorporating vLLM. If immediate upgrading is not possible, restrict vLLM instances to loading only models from internally managed, audited repositories; audit all currently loaded model config.json files for suspicious auto_map entries; and restrict network egress from vLLM processes to only approved Hugging Face repositories. Note that setting trust_remote_code=False alone does not mitigate this vulnerability in affected versions.

The vulnerability was reported by security researcher Vancir, with remediation developed by Isotr0py and reviewed by DarkLight1337, coordinated by russellb of the vLLM project (Github Advisory). ZeroPath published a technical blog post analyzing the RCE via the auto_map mechanism (ZeroPath Blog). A Medium article on vLLM production security hardening for enterprise deployments referenced this vulnerability as a key concern for AI/ML infrastructure operators. Red Hat responded with multiple security errata for their products, indicating broad downstream impact across enterprise AI deployments.