Summary
LightLLM contains an unsafe deserialization flaw in the internal pd_kv_trans_params handling for the /generate endpoint. An unauthenticated attacker may submit crafted parameters that cause deserialization to fail, terminate the inference worker thread, and prevent later requests from completing until the service is restarted.
LightLLM contains an unsafe deserialization flaw in the internal pd_kv_trans_params handling for the /generate endpoint. An unauthenticated attacker may submit crafted parameters that cause deserialization to fail, terminate the inference worker thread, and prevent later requests from completing until the service is restarted.
Affected context
The issue occurs in LightLLM deployments where the /generate endpoint is reachable and processes the internal pd_kv_trans_params field through pickle deserialization. The service may remain responsive to health checks while the inference worker is no longer able to process requests, creating a mismatch between reported health and actual availability.
The issue occurs in LightLLM deployments where the /generate endpoint is reachable and processes the internal pd_kv_trans_params field through pickle deserialization. The service may remain responsive to health checks while the inference worker is no longer able to process requests, creating a mismatch between reported health and actual availability.
Exploit preconditions
- Attack surface: The LightLLM
/generateHTTP endpoint - Required access: No authentication, if the endpoint is exposed to the attacker
- Trigger point: Processing of the
pd_kv_trans_paramsfield during inference request handling - Why exploitation is possible: Crafted serialized input can cause
pickle.loadsto raise an unhandled failure inInferSamplingParams, terminating the inference thread and leaving subsequent requests unable to complete
- Attack surface: The LightLLM
/generateHTTP endpoint - Required access: No authentication, if the endpoint is exposed to the attacker
- Trigger point: Processing of the
pd_kv_trans_paramsfield during inference request handling - Why exploitation is possible: Crafted serialized input can cause
pickle.loadsto raise an unhandled failure inInferSamplingParams, terminating the inference thread and leaving subsequent requests unable to complete
Why this happens
The vulnerability results from deserializing request-controlled data with a general-purpose object deserialization mechanism. Pickle data is not inherently a safe interchange format for untrusted input, and failures during deserialization may also disrupt worker availability when they are not contained by robust error handling. This maps to CWE-502: Deserialization of Untrusted Data.
The vulnerability results from deserializing request-controlled data with a general-purpose object deserialization mechanism. Pickle data is not inherently a safe interchange format for untrusted input, and failures during deserialization may also disrupt worker availability when they are not contained by robust error handling. This maps to CWE-502: Deserialization of Untrusted Data.
Potential impact
- The inference worker may stop processing requests
- Subsequent inference requests could hang or time out
- Service availability may be reduced while health checks continue to pass
- Operators may need to restart affected workers
- Repeated requests could cause sustained denial of service
- The inference worker may stop processing requests
- Subsequent inference requests could hang or time out
- Service availability may be reduced while health checks continue to pass
- Operators may need to restart affected workers
- Repeated requests could cause sustained denial of service
General mitigation guidance
Mitigation generally focuses on removing trust in client-supplied serialized objects and containing failures at the request boundary.
Common defensive patterns include:
- Replacing pickle-based request deserialization with a restricted, data-only format
- Rejecting or tightly validating internal-only fields such as
pd_kv_trans_params - Applying strict schemas, type checks, and size limits before processing parameters
- Catching deserialization and parameter-processing failures without terminating worker threads
- Separating liveness and readiness checks so failed inference capacity is reported accurately
- Restricting endpoint exposure through authentication, authorization, network policy, and rate limiting
- Running inference workers with minimal privileges and isolated process boundaries
Mitigation generally focuses on removing trust in client-supplied serialized objects and containing failures at the request boundary.
Common defensive patterns include:
- Replacing pickle-based request deserialization with a restricted, data-only format
- Rejecting or tightly validating internal-only fields such as
pd_kv_trans_params - Applying strict schemas, type checks, and size limits before processing parameters
- Catching deserialization and parameter-processing failures without terminating worker threads
- Separating liveness and readiness checks so failed inference capacity is reported accurately
- Restricting endpoint exposure through authentication, authorization, network policy, and rate limiting
- Running inference workers with minimal privileges and isolated process boundaries
How teams detect issues like this
Detection may include static analysis for pickle.loads or equivalent deserialization of request-derived data, along with code review of internal fields accepted by public endpoints. Dynamic testing can verify that malformed parameter representations produce bounded client errors rather than worker termination. Runtime monitoring should correlate request failures, thread exits, queue growth, stalled inference calls, and discrepancies between health responses and actual request processing. API policies can also flag unauthenticated access to administrative or internal parameter fields.
Detection may include static analysis for pickle.loads or equivalent deserialization of request-derived data, along with code review of internal fields accepted by public endpoints. Dynamic testing can verify that malformed parameter representations produce bounded client errors rather than worker termination. Runtime monitoring should correlate request failures, thread exits, queue growth, stalled inference calls, and discrepancies between health responses and actual request processing. API policies can also flag unauthenticated access to administrative or internal parameter fields.
