Listen to this Post
The vulnerability arises because lmdeploy unconditionally sets `trust_remote_code=True` when calling HuggingFace Transformers APIs. An attacker who controls the `model_path` parameter (e.g., via deployment configuration, CI/CD, Kubernetes, or user-submitted model ID) can point lmdeploy to a malicious HuggingFace repository. During model initialization, Transformers downloads and executes arbitrary Python code from that repository. The vulnerable call sites are in `lmdeploy/archs.py` (lines 154, 157) and `lmdeploy/utils.py` (line 225), where AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and `GenerationConfig.from_pretrained()` are invoked with trust_remote_code=True. No CLI flag or user opt‑in is required. The lmdeploy serving process then runs the attacker’s code with its own privileges – potentially accessing GPU resources, cloud credentials, internal APIs, and request data. The issue is confirmed in lmdeploy version ≤0.12.3 and on the `main` branch. A proof‑of‑concept simulates loading a fake model that writes a marker file, demonstrating that code execution occurs as soon as the model path is loaded. This is security‑sensitive because `trust_remote_code=True` is explicitly documented as dangerous, yet lmdeploy hardcodes it, removing any trust decision from the operator.
dailycve form (3 words max per line):
Platform: lmdeploy
Version: ≤0.12.3
Vulnerability: Hardcoded trust_remote_code
Severity: Critical
date: 2025-05-21
Prediction: 2025-06-15
What Undercode Say:
Analytics: The vulnerable pattern appears in three core files. A simple grep reveals:
grep -rn "trust_remote_code=True" lmdeploy/ --include=".py"
To check if your deployment is affected:
pip show lmdeploy | grep Version If version <= 0.12.3, vulnerable
Monitor for unexpected model paths in your serving configuration:
kubectl get configmap -A | grep -i "model_path"
Exploit:
- Attacker creates a HuggingFace repo `attacker-org/malicious-model` containing a `config.json` and a custom `modeling_.py` file with payload.
- Attacker modifies the lmdeploy deployment to use `model_path=attacker-org/malicious-model` (e.g., via environment variable, Helm value, or launch command).
- When lmdeploy starts `api_server` with that path, Transformers downloads the repo and executes the custom code during
AutoConfig.from_pretrained(). - Payload runs as the serving process (e.g., reads
/etc/secrets, exfiltrates API keys, spawns a reverse shell).
Protection from this CVE:
- Upgrade to a patched version (not yet available at time of writing). As a workaround, fork lmdeploy and change `trust_remote_code=False` in `archs.py` and
utils.py, then rebuild. - Restrict which HuggingFace repositories can be loaded: use a local model cache and disable remote loading via `TRANSFORMERS_OFFLINE=1` (though this may break legitimate models).
- Run lmdeploy with minimal privileges (non‑root, read‑only filesystem, no internet access except to allowed model hosts).
- Use admission controllers (e.g., OPA) to prevent untrusted model paths in Kubernetes deployments.
Impact:
Arbitrary code execution with the lmdeploy process’s privileges. Attackers can steal cloud/HuggingFace tokens, modify model outputs, access request data, pivot to internal services, and cause denial of service. The impact is critical because lmdeploy often runs with GPU access and high‑value credentials.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
