lmdeploy <= latest contains a code injection vulnerability in lmdeploy/pytorch/config.py line 620 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 the model with lmdeploy, the quant_dtype is passed to eval(f'torch.{quant_dtype}') without any validation.
LMDeploy's PyTorch DistServe/PD-disaggregation control plane used recv_pyobj() to deserialize messages received through a ZeroMQ PULL socket. PyZMQ implements recv_pyobj() using Python pickle deserialization, which can execute arbitrary code while reconstructing an object. The peer address used by the receiver was supplied through the POST /distserve/p2p_connect HTTP endpoint. An attacker who could reach an affected DistServe API server could cause the server to connect to an attacker-controlled ZeroMQ endpoint and deserialize …
The URL checking logic in lmdeploy has a logical flaw that could be bypassed by attackers, leading to SSRF attacks.
The LMdeploy implements an rpc server (AsyncRPCServer in zmq_rpc.py) for supporting the RPC communications. In its core functionality call_and_response(), I found it will directly use the pickles.loads() to deserialize the received messages without any sanitization, hence resulting in a remote code execution vulnerability by this RPC server.
📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain" The accurate description of this vulnerability is: "get_model_arch and related helpers hardcode trust_remote_code=True with no opt-out, creating an implicit unsafe remote-code load path on every model fetch." What this report does NOT claim: It is NOT a network-attack RCE — the user supplies the model reference; LMDeploy honors it. It is NOT a "supply chain" CVE in the classical sense (where …
lmdeploy hardcodes trust_remote_code=True in multiple HuggingFace model-loading call sites. The affected code paths are in: lmdeploy/archs.py lmdeploy/utils.py The vulnerable call sites pass trust_remote_code=True into HuggingFace Transformers APIs such as AutoConfig.from_pretrained(), PretrainedConfig.get_config_dict(), and GenerationConfig.from_pretrained(). Because the model path is supplied by the operator or deployment configuration, an attacker who can control the model_path used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts …
A Server-Side Request Forgery (SSRF) vulnerability exists in LMDeploy's vision-language module. The load_image() function in lmdeploy/vl/utils.py fetches arbitrary URLs without validating internal/private IP addresses, allowing attackers to access cloud metadata services, internal networks, and sensitive resources.
An insecure deserialization vulnerability exists in lmdeploy where torch.load() is called without the weights_only=True parameter when loading model checkpoint files. This allows an attacker to execute arbitrary code on the victim's machine when they load a malicious .bin or .pt model file. CWE: CWE-502 - Deserialization of Untrusted Data
A vulnerability was found in InternLM LMDeploy up to 0.7.1. It has been classified as critical. Affected is the function load_weight_ckpt of the file lmdeploy/lmdeploy/vl/model/utils.py of the component PT File Handler. The manipulation leads to deserialization. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.
A vulnerability was found in InternLM LMDeploy up to 0.7.1. It has been declared as critical. Affected by this vulnerability is the function Open of the file lmdeploy/docs/en/conf.py. The manipulation leads to code injection. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.