InternLM LMDeploy versions 0.9.0 through 0.18.0 have a critical unauthenticated remote code execution flaw: an attacker who sends crafted pickled data to the /update_weights endpoint can run OS commands on the server.
What Is It
CVE-2026-119706 is an insecure deserialization vulnerability (CWE-502) in InternLM LMDeploy. According to the NVD record, an attacker can send a base64-encoded, crafted pickle in the serialized_named_tensors field of a request to the /update_weights endpoint. LMDeploy passes that data to ForkingPickler.loads, which deserializes it without validation. The attacker's commands then run with the privileges of the api_server process.
VulnCheck disclosed the flaw, and NVD published the record on 2026-10-30. NVD currently lists its status as "Deferred."
Why It Matters
- CVSS 3.1: 9.8 (CRITICAL). Vector:
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - CVSS 4.0: 9.3 (CRITICAL)
- Authentication: none required, and no user interaction is needed
- CISA SSVC assessment: exploitation status is
poc, automatable isyes, and technical impact istotal
Anyone who can reach an exposed LMDeploy API server over the network could take full control of the host process. Because a public proof of concept exists and CISA rates the attack as automatable, opportunistic scanning is a realistic risk.
KEV status: CVE-2026-119706 is not in the CISA Known Exploited Vulnerabilities catalog at the time of writing, so CISA has not confirmed active exploitation. No KEV remediation deadline or required action applies.
What's Vulnerable
- Vendor: InternLM
- Product: lmdeploy (
pkg:pypi/lmdeploy) - Affected versions: 0.9.0 through 0.18.0, inclusive (semver)
- Vulnerable component: the
/update_weightsmanagement endpoint in the OpenAI-compatible API server (lmdeploy/serve/openai/endpoints/management.py). The deserialization happens inlmdeploy/turbomind/turbomind.py.
The record lists versions outside this range as unaffected.
Patch Status
The NVD record does not name a fixed release. It does link a related upstream GitHub issue (#4698) and pull request (#4964). Operators should check the upstream repository to see whether that fix has been merged and released.
Until a fixed version is confirmed and deployed, do not expose LMDeploy API servers to untrusted networks, and restrict access to the /update_weights endpoint.