vLLM auto_map Remote Code Execution Chain
A malicious model package can point vLLM to a different, attacker-controlled repository for its actual code, even when a server has disabled remote code execution. vLLM loads and runs that second repository's Python module anyway, giving the attacker code execution inside the vLLM process.
How the attack works
An attacker publishes a normal-looking 'frontend' model repository whose config.json contains an auto_map entry pointing to a separate 'backend' repository they control. When vLLM loads the model, it resolves that auto_map reference with get_class_from_dynamic_module() and fetches the backend repository's Python file, bypassing the trust_remote_code=False setting that should have blocked custom code. That fetched module then executes inside the vLLM process. The detection watches one process tree at a time: it flags the required step of a dynamic Python module being pulled from a different repository than the original config, and corroborates it either by seeing the config-fetch-then-redirect pattern or by the same session immediately spawning a shell, network tool, encoder, or interpreter payload.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7f3c9a41-2d68-4b17-9e05-c8b4a6d21f3e
- Severity
- High
Why it matters
An attacker can get arbitrary code execution inside the model-serving process without the operator ever setting trust_remote_code=True on the malicious repository, potentially leading to data theft, credential access, or further lateral movement from the serving host.
What you can do
- →Pin and vet every repository referenced directly or via auto_map before serving a model; treat auto_map redirects to a different repo as a red flag requiring manual review.
- →Run vLLM model-loading processes with least privilege and no access to credential files or internal network paths they don't need.
- →Monitor for a model-loading process that fetches a .py file from one repository and then spawns a shell, network utility, or encoded payload shortly after.
- →When trust_remote_code is required, restrict it to a known, pinned repository and reject configs whose auto_map points outside that repository.
Known benign look-alikes
- Legitimate trust_remote_code=True workflows where a model's config.json auto_maps to a shared base repository (some multimodal and Nemotron-family checkpoints do this by design). This produces the cross-repo stage without any malicious intent - triage by confirming the backend repository owner.
- Model conversion, quantisation or evaluation pipelines that pull remote modelling code and then legitimately shell out (chmod, bash helper scripts, pip install of a missing kernel package) inside the same Python process tree within the 10 minute window.
- Interactive notebook or dev sessions where an engineer downloads a modelling_*.py from a hub UI and separately runs curl/ssh from the same Python parent.
- CI image builds that fetch model code and post-process it with shell tooling under one python entrypoint.