Summary
LightLLM multimodal deployments through version 1.2.0 expose an unauthenticated RPyC cache service that permits pickle deserialization on all network interfaces. An attacker who can reach the service may submit crafted serialized objects and execute arbitrary code with the privileges of the cache service.
Affected context
The vulnerability occurs in LightLLM multimodal deployments where the RPyC cache service is network-exposed, does not require authentication, and has pickle deserialization enabled for cache operations. Risk is greatest when the service is reachable from untrusted networks or runs with broad operating-system permissions.
Exploit preconditions
- Attack surface: Network-accessible RPyC cache service
- Required access: Network connectivity to the exposed service; authentication may not be required
- Trigger point: Processing serialized data supplied to cache service methods
- Why exploitation is possible: Pickle can reconstruct attacker-controlled objects, and deserialization occurs with the service process's privileges
Why this happens
The underlying bug is the use of Python pickle deserialization across an unauthenticated network service. Pickle is capable of invoking object reconstruction behavior that is not limited to passive data parsing, so treating received serialized data as trusted enables attacker-controlled code execution. This maps to CWE-502: Unsafe Deserialization.
Potential impact
- An attacker may execute arbitrary code in the LightLLM service context
- The service account or container may be compromised
- Sensitive data accessible to the process could be disclosed or modified
- The host or surrounding workloads could be affected if privileges and network access permit
- The deployment could be used for lateral movement or service disruption
General mitigation guidance
Mitigation generally focuses on removing executable deserialization from network-facing interfaces and reducing the trust placed in cache data.
Common defensive patterns include:
- Replacing pickle-based transport or storage with a data-only, schema-constrained format
- Requiring authentication and authorization for cache service operations
- Binding administrative or internal services only to explicitly trusted interfaces
- Restricting network exposure through segmentation and allowlisted access policies
- Running the service with least-privilege identities and minimal filesystem and network permissions
- Applying container isolation and read-only controls where practical
- Treating cached and remotely supplied data as untrusted until validated
How teams detect issues like this
Organizations can look for:
- Static analysis findings involving pickle deserialization on network-reachable code paths
- Code review signals showing RPyC or similar RPC endpoints without authentication or authorization
- Configuration checks for services listening on all interfaces
- Network scans identifying exposed cache or RPC ports
- Runtime monitoring for unexpected child processes, command execution, or anomalous service behavior
- Policy enforcement that blocks unsafe serialization libraries in externally reachable components
Automated security review tools may help identify unsafe deserialization APIs and missing access controls during development.
