CVE-2026-103041 in LightLLM
Summary
by MITRE • 09/30/2026
LightLLM through 1.2.0 multimodal deployments expose an unauthenticated RPyC cache service with pickle deserialization enabled on all interfaces. Attackers can send crafted serialized objects to exposed cache methods to execute arbitrary code with service privileges.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified in LightLLM versions up to 1.2.0 represents a critical security misconfiguration within its multimodal deployment architecture, specifically involving the Remote Python Call (RPyC) framework integration. RPyC is designed for distributed computing and remote procedure calls in Python environments, but it requires strict access controls to prevent unauthorized interaction with exposed services. In this specific instance, the cache service associated with the LLM inference pipeline was inadvertently bound to all network interfaces rather than being restricted to localhost or a secure internal subnet. This configuration error effectively exposes the underlying RPC endpoints to any entity capable of reaching the host machine over the network, including unauthenticated external attackers on public internet connections if port forwarding is enabled.
The core technical flaw lies in the combination of an exposed service endpoint and the default security settings of Python's pickle module used for serialization within the cache mechanism. The RPyC server was configured with deserialization capabilities enabled without adequate authentication checks or input validation. When a client connects to this open interface, it can invoke specific methods related to caching operations. Because these methods accept serialized data structures processed via pickle.loads(), an attacker can craft malicious Python objects that contain arbitrary code execution payloads. Upon receipt and processing by the vulnerable service, these crafted objects are deserialized immediately, triggering the embedded exploit logic before any security checks or application-level validation can occur.
This vulnerability maps directly to CWE-502, which describes Deserialization of Untrusted Data, a category of flaws where an attacker manipulates serialized data to influence program flow or execute commands. Furthermore, from a tactical perspective aligned with MITRE ATT&CK techniques, this scenario exemplifies T1059 Command and Scripting Interpreter through Python, as the exploitation vector leverages native language features for remote code execution. The lack of authentication (CWE-306) compounds the severity, allowing any network actor to initiate the attack sequence without needing valid credentials or prior compromise of user accounts.
The operational impact of this vulnerability is severe, resulting in full Remote Code Execution with the privileges of the LightLLM service process. If the service runs under a privileged system account, an attacker gains complete control over the host operating system, potentially leading to data exfiltration, lateral movement within the network, or deployment of additional malware such as cryptominers or ransomware. Even if running in a restricted container environment, successful exploitation could allow escape from sandbox constraints depending on kernel capabilities and configuration, thereby compromising the integrity of the entire inference infrastructure.
Mitigation strategies must prioritize immediate isolation of the affected service until patches are applied. Administrators should restrict network access to the RPyC cache port using firewall rules or security groups, ensuring it is only accessible by trusted internal clients rather than all interfaces. Upgrading LightLLM to a version greater than 1.2.0 where this exposure has been remediated is essential for long-term resolution. Additionally, organizations should audit their deployment configurations to ensure that no other RPC services are exposed publicly and consider implementing network segmentation to limit the blast radius of potential future vulnerabilities in distributed AI systems.