CVE-2026-111160 in LightLLM
Summary
by MITRE • 10/15/2026
LightLLM through 1.2.0 contains a denial of service vulnerability that allows unauthenticated attackers to crash the inference worker by supplying the internal pd_kv_trans_params field to the /generate endpoint. Attackers can send a single request whose parameters cause pickle.loads to fail in InferSamplingParams, killing the inference thread while /health stays up and all later requests hang until restart.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/16/2026
LightLLM versions through 1.2.0 are susceptible to a critical denial of service vulnerability that stems from improper input validation within the model serving infrastructure. The flaw resides in the handling of internal parameters, specifically the pd_kv_trans_params field, which is exposed via the /generate endpoint without sufficient sanitization or type checking. This architectural oversight allows unauthenticated attackers to exploit the system by crafting a malicious request containing malformed data intended for this internal parameter. Because LightLLM relies on Python's pickle module for deserializing certain input structures, particularly within the InferSamplingParams class, the application attempts to process these unsanitized inputs using pickle.loads. The vulnerability is rooted in CWE-20 Improper Input Validation and CWE-502 Deserialization of Untrusted Data, as the system fails to restrict or validate the structure and content of data passed through public-facing endpoints before it reaches internal deserialization logic.
The operational impact of this vulnerability is severe for service availability. When an attacker submits a request with specifically crafted parameters targeting pd_kv_trans_params, the pickle.loads function encounters unexpected data structures that cause it to fail catastrophically. This failure triggers an unhandled exception within the inference worker thread responsible for processing requests. Consequently, the specific inference thread crashes and terminates immediately. While the overall LightLLM service remains operational because the /health endpoint continues to report a healthy status, the loss of the inference worker creates a significant degradation in performance and reliability. The system does not automatically recover or restart the crashed thread seamlessly; instead, it enters a degraded state where subsequent requests are queued but cannot be processed effectively.
This situation leads to a persistent denial of service condition for legitimate users. As new requests arrive at the /generate endpoint, they hang indefinitely because there is no available inference worker to handle them. The system appears responsive on surface-level health checks, masking the underlying failure from automated monitoring tools that rely solely on status codes or health endpoints. This discrepancy between perceived availability and actual functional capacity makes detection difficult without deep packet inspection or log analysis of worker thread states. Attackers can exploit this by sending a single request to initiate the crash, effectively taking down the inference capability until an administrator manually restarts the service or implements automated recovery mechanisms that are not present in default configurations.
Mitigation strategies must focus on immediate remediation and long-term architectural hardening. The primary recommendation is to upgrade LightLLM to version 1.2.1 or later, where this input validation flaw has been addressed by developers who likely implemented stricter type checking for internal parameters exposed via public APIs. For environments that cannot immediately patch, administrators should restrict access to the /generate endpoint using network-level controls such as firewalls or API gateways to ensure only authenticated and authorized clients can send requests. Additionally, implementing a reverse proxy with request size limits and payload inspection can help block malformed inputs before they reach the application layer. From an ATT&CK perspective, this vulnerability aligns with T1499 Endpoint Denial of Service, as it allows for resource exhaustion through service disruption rather than system crash. Security teams should also audit their deployment configurations to ensure that internal API fields are not inadvertently exposed in public-facing endpoints, adhering to the principle of least privilege and defense-in-depth strategies outlined in industry standards like OWASP API Security Top 10.