EUVD-2026-62972
GHSA-q66m-3fcg-jjh7
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Remote, unauthenticated, low-complexity pickle RCE in default (no api_keys) config yields PR:N/AC:L/AV:N; arbitrary code execution in the engine gives full C:H/I:H/A:H, scope unchanged.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
3DescriptionCVE.org
LMDeploy deserializes disaggregated-serving peer messages with pickle. The handle_zmq_recv coroutine in lmdeploy/pytorch/disagg/conn/engine_conn.py reads peer-to-peer cache-free requests with recv_pyobj(), which deserializes the received bytes with pickle.loads(), and the isinstance check against DistServeCacheFreeRequest runs only after deserialization has already completed. The peer that supplies those bytes is caller-controlled: p2p_connect passes remote_engine_endpoint_info.zmq_address from the request body to connect() on the ZMQ PULL socket, and the POST /distserve/p2p_initialize and /distserve/p2p_connect endpoints in lmdeploy/serve/openai/api_server.py apply no authentication unless the server is started with api_keys, which defaults to None. A remote attacker can direct an engine to pull from a ZMQ endpoint under their control and execute arbitrary code in the engine process. Deployments that do not enable disaggregated serving are not affected, because the receive loop is only started once the migration backend accepts the connection.
AnalysisAI
Unauthenticated remote code execution in InternLM LMDeploy (versions 0.9.2 through 0.15.x) allows a remote attacker to execute arbitrary code inside an inference engine process when disaggregated (P2P) serving is enabled. The disaggregation peer-connector deserializes attacker-influenced ZMQ messages with Python pickle before any type validation, and the /distserve/p2p_initialize and /distserve/p2p_connect endpoints require no authentication in the default configuration (api_keys=None). Reported by VulnCheck with a vendor advisory and a public patch; no public exploit or CISA KEV listing identified at time of analysis, though the code path and fix are publicly documented on GitHub.
Technical ContextAI
LMDeploy is InternLM's LLM inference and serving toolkit; the affected component is its PyTorch-backend disaggregated-serving feature, which splits prefill and decode across engines that exchange cache/session messages over ZeroMQ. The root cause is CWE-502 (Deserialization of Untrusted Data): handle_zmq_recv in lmdeploy/pytorch/disagg/conn/engine_conn.py calls recv_pyobj(), which internally runs pickle.loads() on the received bytes, and the isinstance check against DistServeCacheFreeRequest happens only after the object has already been reconstructed - meaning malicious pickle payloads execute during deserialization, before validation can reject them. Because p2p_connect connects a ZMQ PULL socket to remote_engine_endpoint_info.zmq_address taken directly from the caller-supplied request body, the attacker controls which endpoint the engine pulls (and therefore unpickles) bytes from. The vendor fix (commit f05b4ad, v0.16.0) replaces send_pyobj/recv_pyobj with JSON on the wire (send_json/recv_json plus Pydantic model_validate), eliminating the pickle code-execution path. Affected product per CPE: cpe:2.3:a:internlm:lmdeploy.
RemediationAI
Vendor-released patch: upgrade to LMDeploy v0.16.0 or later, which replaces the pickle-based recv_pyobj()/send_pyobj() wire format with JSON plus Pydantic schema validation (commit f05b4ad8bf2e2d84101a1d63b3c44fadd99223b2; release https://github.com/InternLM/lmdeploy/releases/tag/v0.16.0). If you cannot upgrade immediately, apply these specific compensating controls: set api_keys on the API server so the /distserve/p2p_initialize and /distserve/p2p_connect endpoints require authentication (they are unauthenticated when api_keys defaults to None) - trade-off is that all API clients must now present keys; disable disaggregated serving if not required, which fully removes the attack surface since the ZMQ receive loop never starts - trade-off is losing prefill/decode disaggregation performance; and restrict network access to the API server and the disaggregation ZMQ ports to trusted hosts only (firewall/segment them off the internet), so an attacker cannot direct the engine to pull from an endpoint they control. Refer to the VulnCheck advisory and GitHub issue #4804 for details.
Remote code execution in InternLM LMDeploy versions 0.9.1 through 0.10.1 allows unauthenticated network attackers to run
Server-Side Request Forgery (SSRF) in InternLM LMDeploy's vision-language module allows remote unauthenticated attackers
Arbitrary code execution in InternLM LMDeploy 0.11 and earlier: the toolkit calls torch.load() without weights_only=True
A vulnerability was found in InternLM LMDeploy up to 0.7.1. Rated medium severity (CVSS 4.8), this vulnerability is low
A vulnerability was found in InternLM LMDeploy up to 0.7.1. Rated medium severity (CVSS 4.8), this vulnerability is low
Denial of service in InternLM LMDeploy through 0.17.0 lets unauthenticated remote attackers crash the distributed infere
Memory exhaustion in InternLM LMDeploy through 0.17.0 can be triggered by unauthenticated remote attackers who send repe
Server-side request forgery in InternLM lmdeploy's OpenAI-compatible vision API server lets unauthenticated remote attac
Same weakness CWE-502 – Deserialization of Untrusted Data
View allShare
External POC / Exploit Code
Leaving vuln.today