CVE-2026-27893: 
NixOS vulnerability analysis and mitigation

CVE-2026-27893 is a protection mechanism failure vulnerability in vLLM, an inference and serving engine for large language models (LLMs), titled "Hardcoded Trust Override in Model Files Enables RCE Despite Explicit User Opt-Out." Affecting versions 0.10.1 through 0.17.x, two model implementation files (nemotron_vl.py and kimi_k25.py) hardcode trust_remote_code=True when loading sub-components, bypassing the user's explicit --trust-remote-code=False security opt-out. The vulnerability was published on March 26–27, 2026, and patched in version 0.18.0. It carries a CVSS v3.1 base score of 8.8 (High) (Github Advisory, vllm Security Advisory).

The root cause is classified as CWE-693 (Protection Mechanism Failure): two specific files in vLLM's model executor pass a hardcoded trust_remote_code=True argument directly to HuggingFace API calls, overriding the user's global security configuration. Specifically, vllm/model_executor/models/nemotron_vl.py (line 430) calls AutoModel.from_config(config.vision_config, trust_remote_code=True), and vllm/model_executor/models/kimi_k25.py (line 177) calls cached_get_image_processor(self.ctx.model_config.model, trust_remote_code=True). This vulnerability is distinct from prior related CVEs (CVE-2025-66448 and CVE-2026-22807), which fixed auto_map resolution in different code paths — these hardcoded instances survived both earlier patches. The fix replaces the hardcoded values with self.model_config.trust_remote_code to correctly propagate the user's configured setting (vllm Security Advisory, Fix Commit).

Successful exploitation allows an attacker to execute arbitrary Python code on the host system running vLLM by crafting a malicious model repository. Even when operators have explicitly set --trust-remote-code=False to prevent untrusted code execution — a deliberate security control — the hardcoded override nullifies this protection entirely. The impact spans high confidentiality, integrity, and availability, meaning an attacker could exfiltrate sensitive data (including model weights, API keys, or inference data), modify system state, or disrupt service availability on affected vLLM deployments (Github Advisory, vllm Security Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. Exploitation requires user interaction — specifically, a user or automated pipeline must load a NemotronVL or KimiK25 model from a malicious repository — but no privileges are required from the attacker's side. The EPSS score is approximately 0.046% (0.000320), placing it in the 15th percentile for exploitation likelihood. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory).

1. Prepare malicious model repository: Create a HuggingFace-compatible model repository for a NemotronVL or KimiK25 model type. Embed malicious Python code in a custom model class or image processor registered via auto_map in the model's config.json, which will execute when loaded with trust_remote_code=True.
2. Host the repository: Publish the malicious model to HuggingFace Hub or a self-hosted model repository accessible to the target vLLM deployment.
3. Social engineer or supply-chain attack: Convince a target operator or automated pipeline to load the malicious model (e.g., by impersonating a legitimate model, typosquatting a popular model name, or compromising an upstream model source).
4. Trigger model loading: When the target runs vLLM with --trust-remote-code=False and loads the malicious NemotronVL or KimiK25 model, the hardcoded trust_remote_code=True in nemotron_vl.py or kimi_k25.py causes the HuggingFace API to execute the attacker's embedded Python code during model initialization.
5. Achieve code execution: The malicious code runs in the context of the vLLM process, enabling reverse shell establishment, credential theft, data exfiltration, or further lateral movement within the deployment environment (vllm Security Advisory, Fix Commit).

• Logs: vLLM startup or model loading logs showing initialization of NemotronVL or KimiK25 model classes from external or unexpected repositories; Python tracebacks or unusual output during AutoModel.from_config() or cached_get_image_processor() calls.
• Process: Unexpected child processes spawned by the vLLM Python process (e.g., bash, sh, curl, wget, python3) during model loading; unusual network connections initiated by the vLLM process immediately after model initialization.
• Network: Outbound connections from the vLLM host to unknown external IPs or domains shortly after model loading, particularly on non-standard ports; DNS queries for attacker-controlled infrastructure.
• File System: Unexpected new files written to the vLLM working directory, /tmp, or home directory during model loading; new cron jobs, SSH authorized keys, or persistence mechanisms created by the vLLM service account.

The primary remediation is to upgrade vLLM to version 0.18.0 or later, which replaces the hardcoded trust_remote_code=True with the user-configured value in both affected files (Github Advisory, Fix Commit). If immediate upgrading is not possible, restrict vLLM deployments to loading models exclusively from verified, trusted sources and implement network controls to prevent access to untrusted model repositories. Additionally, isolate affected vLLM instances in separate network segments with limited egress, and monitor logs for suspicious model loading activity. Red Hat has also issued security errata (RHSA-2026:8746 and RHSA-2026:10141) for affected Red Hat products.

The vulnerability was reported by researcher "Wernerina" and coordinated by Russell Bryant (Red Hat), who also authored the fix (vllm Security Advisory). Community discussion appeared on Reddit's r/LocalLLaMA, where users noted the irony of a security opt-out being silently overridden by hardcoded values. The Hacker Wire covered the vulnerability, and it was noted in the context of a broader pattern of trust_remote_code bypass issues in vLLM (following CVE-2025-66448 and CVE-2026-22807). Qualys added detection for this vulnerability (detection ID 531087) in their April 2026 application security detections release.