CVE-2026-103040 in LightLLM
Summary
by MITRE • 09/30/2026
LightLLM through 1.2.0 contains a remote code execution vulnerability in the router profiler service when started with --enable_profiling flag. The service exposes an unauthenticated RPyC server with pickle deserialization enabled, allowing attackers to execute arbitrary code by sending crafted serialized objects to the profiler command queue.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The LightLLM framework, specifically through version 1.2.0, contains a critical remote code execution vulnerability within its router profiler service component. This security flaw is directly triggered when the application is launched with the --enable_profiling flag active. Under these conditions, the system initializes an RPyC (Remote Python Communication) server that serves as the backend for profiling operations. However, this implementation fails to enforce proper authentication mechanisms or restrict access controls on the exposed network interface. Consequently, any external actor capable of reaching the service over the network can interact with it without providing valid credentials, creating a direct pathway for exploitation by unauthenticated adversaries.
The core technical flaw lies in the configuration of the RPyC server which has pickle deserialization enabled by default or through specific configuration settings associated with profiling features. Pickle is a Python-specific serialization format that allows objects to be converted into byte streams and subsequently reconstructed. While useful for legitimate data transfer, it poses severe security risks when applied to untrusted input because the unpickling process can execute arbitrary code during object reconstruction. In this vulnerability scenario, attackers are able to send crafted serialized Python objects directly to the profiler command queue. When the server processes these inputs, it invokes unsafe deserialization routines that interpret malicious payloads embedded within the pickle stream. This allows an attacker to achieve remote code execution on the host system running LightLLM with the privileges of the process executing the service.
From a classification perspective, this vulnerability aligns closely with CWE-502, which describes Deserialization of Untrusted Data. The lack of authentication further exacerbates the risk by removing any barrier to entry for potential attackers, making it an open attack vector accessible across network boundaries if the port is exposed. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior maps to T1059 Command and Scripting Interpreter, specifically Python execution capabilities, and potentially T1078 Valid Accounts if credentials were required but bypassed, though here it represents an unauthenticated access vector similar to T1190 Exploit Public-Facing Application. The ability to execute arbitrary code remotely places this vulnerability in the highest severity category due to its potential for complete system compromise.
The operational impact of exploiting this flaw is severe and comprehensive. An attacker who successfully sends a malicious pickle payload can gain full control over the LightLLM process environment. This includes the ability to read sensitive data, modify model weights or configurations, install backdoors, pivot into other internal network segments if the host has broader connectivity, or disrupt service availability by crashing the application. Since Large Language Model inference services often run on high-performance hardware with significant computational resources and may handle proprietary models or user prompts containing confidential information, a successful exploitation could lead to substantial intellectual property theft and privacy violations. Furthermore, because profiling tools are sometimes used in production environments for performance monitoring, this vulnerability persists even when the system is intended for operational use rather than just development testing.
To mitigate this risk, organizations running LightLLM must immediately disable the profiler service if it is not strictly required for active debugging or performance analysis. This can be achieved by ensuring the --enable_profiling flag is omitted during startup. If profiling functionality is essential, administrators should implement strict network-level access controls such as firewall rules to restrict connectivity to the RPyC server port only from trusted management networks rather than exposing it broadly. Additionally, applying code patches that upgrade LightLLM beyond version 1.2.0 where this issue has been addressed by developers is critical. Security teams should also audit their deployment configurations to ensure no other services are running with unnecessary privileges or exposed interfaces without authentication and input validation mechanisms in place. Regular vulnerability scanning of external-facing applications can help identify such misconfigurations before they are exploited.