vLLM Hardcoded trust_remote_code Override
vLLM lets operators disable automatic execution of code bundled inside a model repository by setting trust_remote_code=False. For a handful of model families (Nemotron-VL, Kimi-K2.5), vLLM's own loading code ignores that setting and runs the model's Python code anyway. This turns a security control into a false sense of safety.
How the attack works
An operator launches vLLM and explicitly disables remote code execution, using a flag or environment variable like --trust-remote-code=False, --no-trust-remote-code, or VLLM_TRUST_REMOTE_CODE=0. If the model being loaded is one of the affected architectures, vLLM's internal loading code for that model calls AutoModel.from_config() or cached_get_image_processor() with trust_remote_code hardcoded to True, overriding the user's setting. Arbitrary Python code shipped inside the model repository then runs at load time, regardless of what the operator intended. A separate variant of the same problem occurs when a single command line contains both a disabling flag and an enabling override (for example --hf-overrides with trust_remote_code:true), which directly contradicts itself and also results in code execution.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 6f2c7b41-9d3e-4a58-b0c7-2e1f84d5a9c3
- Severity
- High
Why it matters
An organization that believes it has blocked untrusted code execution from model repositories may still be running arbitrary code from those repositories, because the safety flag does not apply to certain model architectures. This can lead to code execution on the serving host using a model checkpoint as the delivery mechanism.
What you can do
- →Avoid serving Nemotron-VL or Kimi-K2.5 checkpoints from untrusted sources with vLLM until the loading code respects trust_remote_code=False, since the flag does not currently prevent code execution for these architectures.
- →Review the model repository's files for embedded Python code before loading it, rather than relying solely on the trust_remote_code flag.
- →Check deployment scripts, CI pipelines, and wrapper tooling for hardcoded --trust-remote-code=False flags combined with affected model families, and treat any match as needing manual verification rather than automatic trust.
- →Avoid setting contradictory flags (one disabling and one enabling trust_remote_code) in the same command line, and audit existing scripts for this pattern.
Known benign look-alikes
- Advisory reproduction in a lab — a security engineer intentionally runs vLLM with --trust-remote-code=False against a Nemotron-VL or Kimi-K2.5 checkpoint to confirm the bypass. The command line is indistinguishable from the attack; the rule reports rather than blocks precisely because of this.
- CI or deployment wrappers that hardcode --trust-remote-code=False as a hardening default and happen to serve an affected multimodal architecture from an internally vetted checkpoint. The pytest / --dry-run / --help filters remove the common harness forms, but a bespoke shell wrapper will still be reported.
- Wrapper scripts, Makefile targets or systemd/ansible units that echo or log the full vLLM command line before executing it — the echo/logger child process carries the identical string and matches all three selections.
- A locally converted checkpoint whose directory name contains 'nemotron-vl' or 'kimi-k2' but that ships no custom modelling code — the hardcoded override still executes, so this is a low-severity true positive rather than a pure false alarm.
- Documentation or demo command lines pasted into a shell with a template model reference — mitigated by filter_placeholder_model.