Summary
LightLLM's router profiler service can expose an unauthenticated RPyC endpoint that deserializes attacker-controlled pickle data. When profiling is enabled, a remote attacker may send crafted serialized objects to the profiler command queue and execute arbitrary code in the service process.
Affected context
The vulnerability occurs in LightLLM deployments where the router profiler service is started with profiling enabled and exposes its RPyC interface to an attacker-accessible network. Risk is greatest when the service lacks authentication or network restrictions and processes serialized objects received through its profiler command queue.
Exploit preconditions
- Attack surface: Network-accessible router profiler RPyC service
- Required access: No application authentication may be required when the endpoint is reachable
- Trigger point: Processing serialized data submitted to the profiler command queue
- Why exploitation is possible: Pickle deserialization can reconstruct attacker-controlled objects and invoke code during object loading
Why this happens
The underlying issue is the use of pickle-based deserialization for data received from an unauthenticated remote service. Python pickle is capable of reconstructing objects with behavior beyond passive data parsing, so treating network-provided serialized content as trusted can enable arbitrary code execution. This maps to CWE-502: Deserialization of Untrusted Data.
Potential impact
- An attacker may execute arbitrary code in the LightLLM service process
- The service host or container could be compromised
- Sensitive model, prompt, configuration, or credential data could be accessed
- The vulnerable process could be used for lateral movement or workload disruption
- Model-serving operations could be modified, interrupted, or subjected to data manipulation
General mitigation guidance
Mitigation generally focuses on removing unsafe deserialization from network-facing paths and reducing exposure of profiling services.
Common defensive patterns include:
- Replacing pickle or equivalent executable serialization with a data-only format and strict schema
- Requiring authentication and authorization for profiler and administrative interfaces
- Binding profiling services to protected interfaces and limiting access through network policy
- Disabling profiling by default unless it is operationally required
- Running the service with least privilege and minimizing accessible credentials and filesystem resources
- Treating all network-provided serialized data as untrusted, even inside internal networks
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules identifying pickle deserialization or equivalent object reconstruction on network-derived data
- Code review signals such as unauthenticated RPyC endpoints, remote command queues, and profiler services exposed beyond trusted administration networks
- Runtime inventory checks for profiling flags and externally reachable service ports
- Network monitoring for unexpected connections to profiler or RPyC interfaces
- Policy enforcement requiring authentication, segmentation, and approved data-only serialization formats for administrative services
- Automated security review tools that flag unsafe deserialization and exposed management interfaces
