Summary
A critical unsafe deserialization vulnerability in LightLLM visual_only deployments exposes an unauthenticated RPyC service that accepts attacker-controlled serialized arguments. An attacker who can reach the visual RPyC port may execute arbitrary code with the privileges of the service account.
Affected context
The vulnerability occurs in LightLLM visual_only deployments where:
- An RPyC service is exposed on a reachable network port
- The service permits unauthenticated connections
- Pickle-based argument handling is enabled
- The
remote_infer_imagesmethod deserializes caller-supplied objects
Exposure depends on network configuration, service binding, and whether access controls restrict the RPyC endpoint.
Exploit preconditions
- Attack surface: Network-accessible RPyC service
- Required access: Ability to connect to the exposed visual RPyC port; authentication is not required by the vulnerable configuration
- Trigger point: Processing attacker-controlled arguments passed to
remote_infer_images - Why exploitation is possible: Pickle-enabled deserialization can invoke behavior defined by serialized objects before normal application-level validation is complete
Why this happens
The underlying bug is the use of unsafe, pickle-based deserialization for data received through an unauthenticated remote procedure call interface. Pickle can reconstruct objects using attacker-influenced reduction behavior, causing deserialization to perform operations beyond passive data parsing. This maps to CWE-502: Deserialization of Untrusted Data, because network-supplied content is treated as trusted executable object state.
Potential impact
- An attacker may execute arbitrary code in the LightLLM service process
- The attacker could access data and resources available to the service account
- The deployment may be used for unauthorized inference activity or data manipulation
- Compromised credentials or accessible network paths could enable lateral movement
- The host or surrounding workload could be affected depending on isolation and privileges
General mitigation guidance
Mitigation generally focuses on removing executable deserialization from network-facing interfaces and reducing trust in remote callers.
Common defensive patterns include:
- Replacing pickle-based transport or argument handling with a restricted, data-only serialization format
- Disabling object reconstruction and unsafe deserialization features such as unrestricted pickle handling
- Requiring authentication and authorization for RPyC services
- Binding administrative or internal RPC endpoints to restricted interfaces and enforcing network policy
- Validating arguments against strict schemas after parsing with non-executable formats
- Running the service with a dedicated, least-privileged account and strong process isolation
- Limiting filesystem, credential, and network access available to the service
How teams detect issues like this
Detection can combine code analysis, deployment review, and runtime monitoring:
- Search source and dependencies for pickle-enabled RPC configuration, unrestricted deserialization, and dynamic object reconstruction
- Review RPC methods that accept serialized objects or generic arguments from remote clients
- Check whether visual inference services expose RPyC ports without authentication or network restrictions
- Enforce policies that prohibit executable serialization on network-facing endpoints
- Monitor for unexpected connections to the RPyC port, anomalous method calls, child-process creation, and service-account activity outside expected inference behavior
- Use automated static analysis and dependency review tools to flag unsafe deserialization patterns
