Description

LightLLM through 1.2.0 contains a remote code execution vulnerability in the Config Server's unauthenticated /visual_register WebSocket endpoint that passes the first client frame directly to pickle.loads(). Attackers can reach the Config Server port and send a malicious serialized payload with a __reduce__ method to execute arbitrary code with Config Server process privileges.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-14T12:17:51.807Z",
  "pubdate": "2026-09-14T12:17:51.807Z",
  "executiveSummary": "LightLLM versions up to 1.2.0 are susceptible to a critical Remote Code Execution (RCE) vulnerability within the Config Server component.\nThe vulnerability originates from the insecure deserialization of untrusted data via the /visual_register WebSocket endpoint.\nBy sending a crafted payload to the unauthenticated endpoint, an attacker can trigger arbitrary code execution under the privileges of the Config Server process.\nThis flaw poses a severe risk to system integrity and confidentiality, as it allows remote adversaries to execute system-level commands without prior authentication.\nThe exploitation requirement is limited to network reachability of the Config Server port, making it a high-priority threat for deployments exposed to network segments accessible by untrusted entities.\nSuccessful exploitation grants an attacker full control over the affected process, potentially facilitating lateral movement within the network or persistent system compromise.",
  "technicalDetails": "The vulnerability resides in the Config Server component of LightLLM, specifically within the /visual_register WebSocket endpoint. The root cause is the unsafe use of the Python 'pickle' module to deserialize incoming client frames.\nThe application processes the first WebSocket frame received on the /visual_register endpoint by passing the raw binary data directly to the 'pickle.loads()' function without implementing any signature verification, input validation, or object filtering mechanisms.\nBecause the 'pickle' protocol inherently supports the instantiation of arbitrary Python objects through the '__reduce__' method, an attacker can craft a malicious serialized payload. When 'pickle.loads()' deserializes this payload, the interpreter executes the instructions defined within the '__reduce__' method, leading to arbitrary code execution.\nThe attack flow begins when an attacker establishes a WebSocket connection to the Config Server port. No authentication handshake is required to access the /visual_register endpoint. The attacker transmits a serialized byte stream constructed using the 'pickle' protocol. This stream contains the payload designed to invoke system commands—such as spawning a reverse shell or executing arbitrary shell scripts—via the underlying operating system.\nUpon receiving the malicious frame, the Config Server's event loop passes the payload to the vulnerable function. The Python interpreter restores the object, triggering the execution of the attacker's code. Since the Config Server typically runs with specific process privileges, the injected code inherits these permissions, granting the attacker significant capability to manipulate the file system, exfiltrate environment variables, or execute further malicious payloads.\nThis vulnerability is present in all LightLLM versions up to and including 1.2.0. The lack of integrity checking on serialized data makes this a classic insecure deserialization flaw, which is particularly dangerous in network-facing components. Any entity capable of initiating a WebSocket handshake with the Config Server can successfully exploit this vulnerability, as there are no identity verification gates before the deserialization logic is invoked."
}