vLLM's auto_map RCE: a model config that runs remote code even with trust_remote_code off

What happened

vLLM is a high-throughput inference and serving engine for LLMs. In December 2025, CVE-2025-66448 was disclosed: vLLM would execute remote code contained in a model's configuration even when the operator had explicitly set the trust_remote_code=False safety flag.

The flaw lived in how vLLM processed auto_map entries in a model's config through the get_class_from_dynamic_module function. When loading a model whose config contained an auto_map entry, vLLM fetched and executed the Python code from the remote repository the auto_map string referenced — bypassing the trust_remote_code boundary that operators rely on to opt out of exactly this behavior. An attacker could publish a benign-looking "frontend" model repository whose config pointed auto_map at a separate "backend" repository holding malicious code, achieving silent execution on any host that loaded the model. All versions before 0.11.1 are affected. The fix introduces domain validation, restricting dynamic module loading to trusted sources (such as GitHub and PyPI) before any execution proceeds. The weakness is classified CWE-94, Code Injection.

Root cause

A security control was declared but not enforced. Operators set trust_remote_code=False expecting no remote code to run, but the auto_map code path ignored that flag and executed remote Python anyway. Combined with an ecosystem where anyone can publish a model, this is an OWASP LLM03 Supply Chain and LLM04 Model Poisoning failure: the model artifact itself carried executable payload, and the guardrail meant to stop it was inert.

How it would have been caught

A test that loads a model with trust_remote_code=False whose config's auto_map points at a repository containing a canary side effect — and asserts the canary never fires — would have failed on the vulnerable build, exposing the bypass. More broadly, treating every downloaded model as untrusted code and loading it inside an egress-restricted sandbox would have contained it.

How to prevent it

• Upgrade vLLM to 0.11.1 or later.
• Only load models from repositories you control or have vetted; pin by digest.
• Load models inside a sandbox with no outbound network and least privilege, so a code-execution attempt cannot phone home or persist.
• Do not treat trust_remote_code=False as sufficient isolation — enforce it with the runtime boundary, not just the flag.

The Breachwire test (red → green)

Load a model with trust_remote_code=False whose auto_map references a repo that writes a canary file, and confirm the canary appears (RED — remote execution despite the flag). Upgrade to the domain-validated version and run inside an egress-jailed sandbox, then confirm the canary never fires while a legitimate, vetted model still loads and serves correctly.