Loading vulnerability…
Remote Code Execution in vLLM trust_remote_code Handling
CVE-2026-27893 is a remote code execution vulnerability in vLLM, an inference and serving engine for large language models. In versions starting at 0.10.1 and prior to 0.18.0, two model implementation files hardcode trust_remote_code=True while loading sub-components. This behavior overrides the user's explicit --trust-remote-code=False setting, defeating the intended security control that disables execution of repository-supplied custom code. As a result, loading a malicious model repository can cause arbitrary Python code from that repository to be executed despite the user's attempt to opt out of remote code trust.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows arbitrary code execution in the context of the vLLM process when a malicious model repository is loaded through the affected code paths. This can result in full compromise of the confidentiality, integrity, and availability of the host environment accessible to that process, including theft or manipulation of model data, credentials, prompts, outputs, and service configuration, as well as disruption of inference services.
If you can’t patch tonight, do this now.
Until an upgrade can be applied, do not load untrusted or third-party model repositories with affected vLLM versions. Restrict model sources through strict allowlisting, prefer vetted internal mirrors or reviewed repositories, and isolate model-loading workloads using strong sandboxing and least-privilege execution to limit the impact of code execution. Additional compensating controls include network egress restrictions, separation of sensitive credentials from the inference runtime, and avoiding model paths known to exercise the vulnerable sub-component loading behavior.
Patch, then assume compromise.
Upgrade vLLM to version 0.18.0 or later, which patches the vulnerable behavior. The effective fix is to ensure model-loading code respects the user-controlled trust setting rather than forcing trust_remote_code=True, and to fail safely when a model requires remote code but explicit trust has not been enabled.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
5 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.