CVE-2026-76850: Deserialization of Untrusted Data in InternLM lmdeploy
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.
AI Analysis
Technical Summary
The vulnerability in InternLM lmdeploy involves unsafe deserialization of untrusted data using pickle.loads() in the handle_zmq_recv coroutine. The deserialization occurs before verifying the object's type, and the peer supplying the data is caller-controlled through ZeroMQ endpoints that lack authentication unless api_keys are explicitly enabled. This enables a remote attacker to direct the engine to connect to a malicious ZeroMQ endpoint and execute arbitrary code within the engine process. Deployments without disaggregated serving enabled are not vulnerable because the receive loop is not started.
Potential Impact
An unauthenticated remote attacker can exploit this vulnerability to execute arbitrary code on the engine process by sending crafted messages to the ZeroMQ endpoint. This can lead to full compromise of the affected system running lmdeploy with disaggregated serving enabled.
Mitigation Recommendations
No official patch or fix is currently provided. Users should enable api_keys authentication to restrict access to the ZeroMQ endpoints or disable disaggregated serving to avoid exposure. Monitor vendor advisories for updates and patches addressing this vulnerability.
CVE-2026-76850: Deserialization of Untrusted Data in InternLM lmdeploy
Description
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.
CVSS v4.0
Score 9.3critical
Affected software
InternLM
lmdeploy
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability in InternLM lmdeploy involves unsafe deserialization of untrusted data using pickle.loads() in the handle_zmq_recv coroutine. The deserialization occurs before verifying the object's type, and the peer supplying the data is caller-controlled through ZeroMQ endpoints that lack authentication unless api_keys are explicitly enabled. This enables a remote attacker to direct the engine to connect to a malicious ZeroMQ endpoint and execute arbitrary code within the engine process. Deployments without disaggregated serving enabled are not vulnerable because the receive loop is not started.
Potential Impact
An unauthenticated remote attacker can exploit this vulnerability to execute arbitrary code on the engine process by sending crafted messages to the ZeroMQ endpoint. This can lead to full compromise of the affected system running lmdeploy with disaggregated serving enabled.
Mitigation Recommendations
No official patch or fix is currently provided. Users should enable api_keys authentication to restrict access to the ZeroMQ endpoints or disable disaggregated serving to avoid exposure. Monitor vendor advisories for updates and patches addressing this vulnerability.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- VulnCheck
- Date Reserved
- 2026-08-19T21:24:37.594Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6a8625a9acd9273b49aaf2b8
Added to database: 08/19/2026, 21:52:41 UTC
Last enriched: 09/25/2026, 02:41:56 UTC
Last updated: 10/03/2026, 14:46:10 UTC
Views: 134
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.