CVE-2026-90919 in LightLLM
Summary
by MITRE • 09/14/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The LightLLM framework, specifically through version 1.2.0, contains a critical remote code execution vulnerability within its configuration server component. This flaw is located in the unauthenticated WebSocket endpoint designated as /visual_register. The security issue stems from an insecure deserialization mechanism where the application accepts input from clients without any form of authentication or access control verification. When a client connects to this specific endpoint, the system processes incoming data frames and directly passes the first frame received to Python's pickle.loads() function for parsing. This design choice bypasses standard safety checks that would typically validate the source or integrity of serialized objects before deserialization occurs.
The technical root cause of this vulnerability is the direct invocation of pickle.loads on untrusted input. The Python pickle module, while convenient for serializing and deserializing complex object structures, is inherently unsafe when used with data from untrusted sources because it can execute arbitrary code during the unpickling process. An attacker who has network access to the Config Server port can craft a malicious serialized payload containing a class that implements the _reduce_ method. When this payload is processed by pickle.loads(), the _reduce_ method is invoked, allowing the execution of arbitrary system commands or logic with the same privileges as the LightLLM Config Server process. This represents a classic instance of insecure deserialization where user-controlled data influences critical application behavior without proper validation.
From an operational perspective, this vulnerability poses a severe risk to the integrity and availability of systems running vulnerable versions of LightLLM. Successful exploitation allows remote attackers to achieve full control over the server environment hosting the Config Server. This can lead to complete compromise of the underlying operating system, theft or manipulation of sensitive data processed by the LLM framework, and potential pivoting into other parts of the network infrastructure. Since the endpoint is unauthenticated, any entity with network connectivity to the service port can attempt exploitation, significantly expanding the attack surface beyond just authenticated users or trusted internal networks if the server is exposed externally without proper firewall rules.
This vulnerability aligns with CWE-502, which describes Deserialization of Untrusted Data, a category of flaws where applications deserialize data from untrusted sources without sufficient validation, leading to remote code execution. In terms of offensive security frameworks, this exploitation technique maps to MITRE ATT&CK T1608, specifically the use of Spearphishing Attachment or more broadly in this context, it relates to techniques involving server-side request forgery and deserialization attacks often categorized under Initial Access or Execution tactics depending on the specific payload delivery method. The lack of authentication further exacerbates the risk by removing a critical layer of defense that might otherwise restrict access to authorized personnel only.
Mitigation strategies for this vulnerability are straightforward but require immediate action. Organizations running LightLLM versions up to 1.2.0 should upgrade to a patched version where the /visual_register endpoint has been secured with authentication mechanisms and input validation is implemented before deserialization occurs. If upgrading is not immediately feasible, network-level controls such as firewall rules restricting access to the Config Server port to only trusted IP addresses can provide temporary relief. Additionally, implementing strict input sanitization or replacing pickle-based serialization with safer alternatives like JSON for configuration data exchange would eliminate the risk of arbitrary code execution via deserialization flaws. Security teams should also audit their deployment configurations to ensure that internal services are not inadvertently exposed to untrusted networks.