CVE-2026-103395 in LightLLM
Summary
by MITRE • 09/30/2026
LightLLM through 1.2.0 visual_only deployments expose an unauthenticated RPyC service with allow_pickle enabled that deserializes attacker-supplied arguments in the remote_infer_images method. Attackers can reach the visual RPyC port and pass objects with __reduce__ methods to execute arbitrary code with service account privileges.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/30/2026
The vulnerability identified in LightLLM versions through 1.2.0 represents a critical security flaw stemming from improper configuration of remote procedure call services within specific deployment modes. When the system is deployed with visual_only settings enabled, it inadvertently exposes an RPyC service interface to network traffic without requiring authentication. This misconfiguration creates a direct attack vector for unauthenticated adversaries who can connect to the exposed port and interact with the underlying Python runtime environment. The core of this vulnerability lies in the combination of an open remote access point and the enabling of pickle deserialization, which is inherently unsafe when processing data from untrusted sources.
The technical mechanism involves the remote_infer_images method, which accepts arguments passed by clients connecting to the RPyC service. By default or due to specific configuration flags, this service allows for allow_pickle operations during argument parsing. In Python, the pickle module provides a powerful serialization format that can represent arbitrary object graphs. When deserialization is permitted on unauthenticated input, an attacker can craft malicious payloads containing objects with custom _reduce_ methods. These special methods define how an object should be serialized and, crucially, what code to execute upon deserialization. By injecting such crafted objects into the remote_infer_images call stream, the adversary forces the LightLLM service process to instantiate these objects during argument processing.
This exploitation path leads directly to Remote Code Execution with the privileges of the account running the LightLLM service. Since large language model inference engines often require significant computational resources and may run under elevated system accounts or within containerized environments with broad permissions, successful exploitation grants the attacker full control over the host infrastructure. The impact extends beyond simple code execution; it allows for data exfiltration, lateral movement within the network, persistence mechanisms via backdoors installed by the executed payload, and potential denial of service through resource exhaustion. This scenario aligns closely with CWE-502, which describes Deserialization of Untrusted Data, a category of vulnerabilities where applications fail to validate or sanitize input before passing it to deserialization functions that can execute arbitrary code.
From an offensive security perspective, this vulnerability maps directly to the MITRE ATT&CK technique T1059, specifically Command and Scripting Interpreter sub-techniques such as Python (T1059.007). The attacker utilizes the legitimate functionality of the application for malicious purposes, bypassing traditional network-based access controls due to the lack of authentication on the RPyC port. This is a classic example of how internal service misconfigurations can lead to severe compromise even if perimeter defenses are robust. The ability to execute arbitrary code remotely without credentials makes this particularly dangerous in production environments where model serving endpoints must be accessible but also secure against unauthorized manipulation.
Mitigation strategies should focus on immediate remediation and long-term architectural hardening. First, LightLLM deployments using visual_only mode must disable the allow_pickle flag for RPyC services to prevent arbitrary object instantiation during deserialization. If pickle is strictly required for internal communication, it must be restricted to authenticated channels with integrity checks such as HMAC signatures to ensure payload authenticity. Furthermore, administrators should enforce strict network segmentation policies that restrict access to inference ports only from trusted client IP ranges using firewall rules or service mesh configurations. Implementing authentication mechanisms on all remote procedure call interfaces is essential to prevent unauthenticated access regardless of the underlying serialization safety.
In addition to configuration changes, organizations should adopt a principle of least privilege for service accounts running LLM inference engines. By ensuring that the LightLLM process runs with minimal necessary permissions, the blast radius of any potential exploitation is significantly reduced even if other controls fail. Regular vulnerability scanning and penetration testing focused on internal services can help identify similar misconfigurations before they are exploited in the wild. Updating to patched versions of LightLLM where these defaults have been corrected or hardened is critical for maintaining security posture. Ultimately, securing AI infrastructure requires treating model serving components with the same rigor as traditional web applications, emphasizing authentication, input validation, and secure default configurations across all exposed interfaces.