CVE-2026-119706 in LMDeploy
Summary
by MITRE • 10/30/2026
InternLM LMDeploy 0.9.0 through 0.18.0 contains an unauthenticated remote code execution vulnerability that allows remote attackers to run OS commands by sending pickled data to the /update_weights endpoint. Attackers can submit a base64-encoded crafted pickle in serialized_named_tensors, which ForkingPickler.loads deserializes without validation, executing commands as the api_server process.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified within InternLM LMDeploy versions 0.9.0 through 0.18.0 represents a critical security flaw rooted in improper handling of serialized data during model weight updates. This unauthenticated remote code execution (RCE) vulnerability specifically targets the /update_weights endpoint, which is designed to facilitate the transfer and application of new neural network weights for large language models. The core technical failure lies in the deserialization mechanism employed by the ForkingPickler.loads function. When a client submits data via this endpoint, the system accepts base64-encoded pickle objects within the serialized_named_tensors field without performing any form of validation or sanitization before processing them. This lack of input verification allows an attacker to inject malicious Python bytecode into the deserialization stream.
In standard Python environments, the pickle module is not designed for secure data exchange between untrusted sources because it can instantiate arbitrary classes and execute code during the unpickling process. By crafting a specific pickle payload that exploits this behavior, an attacker can force the server-side api_server process to execute operating system commands with the privileges of the user running the application. Since LMDeploy typically runs as part of a serving infrastructure, these privileges are often elevated or sufficient to compromise the underlying host environment. The absence of authentication on the /update_weights endpoint further exacerbates the risk, allowing any network-accessible actor to trigger this code execution without needing valid credentials.
The operational impact of this vulnerability is severe, potentially leading to full system compromise. An attacker who successfully exploits this flaw can read sensitive data stored on the server, install backdoors, pivot to other systems within the internal network, or disrupt service availability by consuming resources or crashing the process. Given that large language model deployments are often central to enterprise AI workflows, such a breach could result in significant intellectual property theft and reputational damage. The vulnerability aligns with CWE-502, which describes Deserialization of Untrusted Data, as well as CWE-78, the OS Command Injection category, highlighting the dual nature of this flaw where insecure deserialization directly facilitates command execution.
To mitigate this risk, immediate action is required to restrict access to the /update_weights endpoint. Organizations should implement network-level controls such as firewalls or API gateways that limit connectivity to this specific route only from trusted internal management networks or authorized administrative interfaces. Additionally, enabling authentication and authorization mechanisms for all model update endpoints ensures that only verified personnel can initiate weight changes. From a development perspective, the use of ForkingPickler.loads should be replaced with safer serialization formats like JSON or Protocol Buffers that do not support arbitrary code execution during deserialization. If pickle must remain in use due to legacy constraints, strict allow-listing of permitted classes and methods within the unpickling context is essential to prevent exploitation. Regular security audits and static analysis tools configured to detect unsafe deserialization patterns can also help identify similar vulnerabilities across the codebase before deployment.