# vLLM auto_map Remote Code Execution Chain

- **Severity:** High
- **Signature ID:** `7f3c9a41-2d68-4b17-9e05-c8b4a6d21f3e`
- **MITRE ATLAS:** AML.T0010 (AI Supply Chain Compromise)
- **OWASP:** LLM03 (Supply Chain)

## Summary

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.

## 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.

## References

- https://attack.mitre.org/techniques/T1195/001/
- https://attack.mitre.org/techniques/T1059/006/
- https://atlas.mitre.org/techniques/AML.T0010
- https://huggingface.co/docs/transformers/en/custom_models
- https://docs.vllm.ai/en/latest/models/supported_models.html

---
Source: https://www.netzilo.com/threats/vllm-automap-remote-code-execution