CVE-2026-22807: 
NixOS vulnerability analysis and mitigation

CVE-2026-22807 is a code injection vulnerability in vLLM, an inference and serving engine for large language models, that allows arbitrary code execution during model initialization via unsafe Hugging Face auto_map dynamic module loading. Affecting vLLM versions 0.10.1 through 0.13.x (prior to 0.14.0), the flaw was disclosed on January 21, 2026, via a GitHub Security Advisory. It carries a CVSS v3.1 base score of 9.8 (Critical) per Feedly/NVD, or 8.8 (High) per the official GitHub advisory (which notes user interaction is required in some scenarios) (GitHub Advisory, Feedly).

The root cause is CWE-94 (Improper Control of Generation of Code / Code Injection). During model resolution, vllm/model_executor/models/registry.py unconditionally iterates auto_map entries from the Hugging Face model config and calls try_get_class_from_dynamic_module, which delegates to Transformers' get_class_from_dynamic_module and executes the referenced Python module code — even when trust_remote_code is set to false (GitHub Advisory). The fix (PR #32194, commit 78d13ea) adds a trust_remote_code parameter to try_get_class_from_dynamic_module and calls resolve_trust_remote_code before executing any dynamic module, gating code execution on the user's trust setting (GitHub PR, GitHub Commit). A public PoC is available on GitHub (PoC).

An attacker who can influence the model repository path — either a local directory or a remote Hugging Face repository — can achieve arbitrary Python code execution on the vLLM host with the privileges of the vLLM server process (GitHub Advisory). Exploitation occurs at server startup, before any API request handling, meaning no API access or authentication is required. Successful exploitation can result in full system compromise including data theft, service disruption, and lateral movement within the hosting environment (Feedly).

A public proof-of-concept exploit is available on GitHub (PoC), published around January 31, 2026. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation. The EPSS score is approximately 0.046% (low probability of near-term exploitation), and the vulnerability is not listed in the CISA KEV catalog. The vulnerability is detectable by Qualys scanners (detection IDs: 5007135, 530867, 6626150, 6634839) (Feedly).

1. Prepare a malicious model repository: Create a Hugging Face model repository (or local directory) containing a config.json with an auto_map entry pointing to a custom Python module (e.g., AutoModelForCausalLM: malicious_repo--malicious_module.MaliciousClass).
2. Embed malicious code: In the referenced Python module file within the repo, include arbitrary code at module level (e.g., a reverse shell, data exfiltration script, or persistence mechanism) that executes on import.
3. Influence model path: Convince or manipulate a vLLM operator to load the malicious model — either by publishing the repo to Hugging Face Hub, supplying a local path, or via supply chain compromise of a legitimate model.
4. Trigger server startup: When the vLLM server starts with the malicious model path (e.g., vllm serve malicious-org/malicious-model), registry.py iterates auto_map entries and calls try_get_class_from_dynamic_module without checking trust_remote_code.
5. Code executes: Transformers' get_class_from_dynamic_module downloads and imports the malicious module, executing the embedded payload on the vLLM host with server process privileges — before any request is served (GitHub Advisory, PoC).

• Process: Unexpected child processes spawned by the vLLM Python process at startup (e.g., bash, sh, curl, wget, python) before any API requests are received.
• Network: Outbound connections from the vLLM host to unknown external IPs or domains initiated during server startup; unexpected DNS lookups to attacker-controlled infrastructure.
• File System: Presence of unexpected Python module files downloaded into the Hugging Face cache directory (typically ~/.cache/huggingface/hub/) from unrecognized or newly created repositories; new cron jobs, SSH keys, or scripts created by the vLLM service account.
• Logs: vLLM startup logs showing dynamic module loading from unexpected or unrecognized model repositories; Python import errors or tracebacks referencing unfamiliar module paths during model initialization; Hugging Face Hub download logs for repositories not in the approved model list.

Upgrade vLLM to version 0.14.0 or later, which includes the fix from PR #32194 (commit 78d13ea) that properly gates auto_map dynamic module loading on the trust_remote_code setting (GitHub Release, GitHub Commit). If immediate upgrade is not possible, restrict model loading to a curated allowlist of trusted repositories, avoid loading models from untrusted or user-supplied paths, and ensure trust_remote_code=False is set (noting this alone does not fully mitigate the vulnerability in affected versions). Implement network-level egress controls on vLLM hosts to limit outbound connections during model initialization, and audit all currently loaded models for unexpected auto_map entries (GitHub Advisory).

The vulnerability was reported by researchers from bugbunny.ai (credited as zaddy6 and arthurgervais) and remediated by DarkLight1337 with coordination from russellb (GitHub Advisory). Endor Labs highlighted the vulnerability in a broader analysis of AI infrastructure security risks, noting it as an example of classic code injection vulnerabilities appearing in modern ML serving stacks (Endor Labs). Red Hat issued an errata (RHSA-2026:3462) addressing the vulnerability in their distributions of vLLM (Red Hat Errata). The vulnerability received coverage from security news outlets including The Hacker Wire and was tracked by multiple vulnerability intelligence platforms.