Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The URL checking logic in lmdeploy has a logical flaw that could be bypassed by attackers, leading to SSRF attacks. Details The current lmdeploy project uses issafeurl to validate the input URL. The main logic is to perform security checks on the host portion of the URL extracted by urlparse to prevent SSRF attacks. <img width="943" height="836" alt="QQ20260416-203956-16-1" src="https://github.com/user-attachments/assets/042faad1-7458-444a-bbc9-525c772b0a4d" / However, there are indeed differences in parsing between urlparse and the library that actually sends the request. Currently, almost all application scenarios in this project involve first using issafeurl for URL validation, and then using requests.Session().get to send the request. <img width="1086" height="576" alt="QQ20260416-204053-16-2" src="https://github.com/user-attachments/assets/7ffb8a69-b155-483a-90be-016c53e6387a" / The core issue: urlparse() and requests disagree on which host a URL like…
Recommended action: Upgrade to 0.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 quantizationconfig.quantdtype value. When a user loads the model with lmdeploy, the quantdtype is passed to eval(f'torch.{quantdtype}') without any validation. Details Vulnerable code (permalink): The quantdtype value comes from the model's quantizationconfig in its HuggingFace config. When a model specifies quantmethod: awq, the AWQ branch processes the config but does NOT override quantdtype, allowing the malicious value to reach the eval() call. Attack vector: An attacker publishes a HuggingFace model with: Note: The updatetorchdtype method at line 53 has a whitelist check, but that's for torchdtype, NOT quantdtype. The quantdtype at line 620 has no validation whatsoever. PoC Output: Impact An attacker who publishes a malicious model on HuggingFace Hub can…
Recommended action: Upgrade to 0.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
LMDeploy's PyTorch DistServe/PD-disaggregation control plane used recvpyobj() to deserialize messages received through a ZeroMQ PULL socket. PyZMQ implements recvpyobj() 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/p2pconnect 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 a crafted pickle payload. API-key authentication is not enabled unless the operator explicitly configures it. As a result, affected DistServe deployments without API keys allowed unauthenticated remote code execution with the privileges of the LMDeploy serving process. This issue affects the PyTorch backend when PD-disaggregation/DistServe is enabled. Ordinary deployments that do not use the affected disaggregated-serving path do not expose this data flow.…
Recommended action: Upgrade to 0.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The LMdeploy implements an rpc server (AsyncRPCServer in zmqrpc.py) for supporting the RPC communications. In its core functionality callandresponse(), 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. Proof of Concept Step1: The victim user starts a RPC server that connects to its network interface. We give our example code (server.py) in the attachment, you can reproduce directly with server.py. Step2: The attacker can then send malicious pickle dump data to the remote RPC address for the attack. We give a example to show how can an attacker acquire a command shell: <img width="832" height="324" alt="image" src="https://github.com/user-attachments/assets/03b9654d-e25b-4e93-903a-2aae8b12e704" / In this example, attacker modifies AsyncRPCClient and send a request containing malicious pickle dump data to let the victim execute command…
Recommended action: Upgrade to 0.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
📋 Reframing (2026-05-02): implicit unsafe remote-code path, not "supply-chain" The accurate description of this vulnerability is: "getmodelarch and related helpers hardcode trustremotecode=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 a benign upstream is compromised) — the user explicitly types the repo name. What this report DOES claim: Other inference frameworks (vLLM, TGI, Hugging Face transformers itself) all expose --trust-remote-code as opt-in so that users who consciously load known-safe repos can opt in, while users following a tutorial cannot accidentally execute attacker Python by typing a wrong repo name. LMDeploy's hardcoded True is an implicit trust-boundary override that violates HF Transformers' default-secure stance…
Recommended action: Upgrade to 0.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
lmdeploy hardcodes trustremotecode=True in multiple HuggingFace model-loading call sites. The affected code paths are in: The vulnerable call sites pass trustremotecode=True into HuggingFace Transformers APIs such as AutoConfig.frompretrained(), PretrainedConfig.getconfigdict(), and GenerationConfig.frompretrained(). Because the model path is supplied by the operator or deployment configuration, an attacker who can control the modelpath used by an lmdeploy serving process can point it to an attacker-controlled HuggingFace model repository. When lmdeploy starts and initializes the model, Transformers may download and execute remote Python code from that repository. Successful exploitation results in arbitrary code execution with the privileges of the lmdeploy serving process. Affected version Confirmed affected: The issue was verified on v0.12.3 and on main. Vulnerable code Confirmed call sites: The vulnerable pattern is: and: The risk is that trustremotecode=True is enabled…
Recommended action: Upgrade to 0.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An insecure deserialization vulnerability exists in lmdeploy where torch.load() is called without the weightsonly=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 --- Details Several locations in lmdeploy use torch.load() without the recommended weightsonly=True security parameter. PyTorch's torch.load() uses Python's pickle module internally, which can execute arbitrary code during deserialization. Vulnerable Locations 1. lmdeploy/vl/model/utils.py (Line 22) 2. lmdeploy/turbomind/deploy/loader.py (Line 122) Additional vulnerable locations: - lmdeploy/lite/apis/kvqparams.py:129-130 - lmdeploy/lite/apis/smoothquant.py:61 - lmdeploy/lite/apis/autoawq.py:101 - lmdeploy/lite/apis/getsmallshardedhf.py:41 Note: Secure Pattern Already Exists The codebase already uses the secure pattern in one location: This…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.