CVE-2026-93839 in LightLLM
Summary
by MITRE • 09/18/2026
LightLLM through 1.2.0 contains an authentication bypass vulnerability in the /pd_register WebSocket endpoint that allows unauthenticated attackers to register arbitrary nodes by supplying crafted JSON without peer address validation. Attackers can disclose full user prompts routed to their socket, trigger denial of service by replacing legitimate nodes, or make the PD Master issue requests to internal network addresses.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in LightLLM versions up to 1.2.0 represents a critical authentication bypass within the distributed inference architecture, specifically targeting the /pd_register WebSocket endpoint. This flaw stems from an insufficient validation of incoming connection metadata and request payloads during the node registration process. In a typical distributed large language model serving setup, such as one utilizing LightLLM's Prompt Dispatcher (PD) Master component, new worker nodes must register with the master to receive inference tasks. The security architecture relies on the assumption that only authorized or pre-configured nodes can successfully complete this handshake. However, due to the absence of peer address validation and strict authentication checks for this specific endpoint, any external actor capable of establishing a WebSocket connection can impersonate a legitimate worker node by submitting crafted JSON payloads. This lack of identity verification effectively nullifies the perimeter security controls intended to isolate internal cluster communications from unauthorized access.
From a technical perspective, the core issue lies in the server-side handling of registration requests where the application fails to verify that the source IP address or network context matches expected parameters for valid nodes. By supplying arbitrary JSON structures without validating the peer's identity, an attacker can trick the PD Master into accepting their machine as part of the trusted cluster infrastructure. This misconfiguration allows the malicious entity to inject itself into the distributed system seamlessly. The vulnerability is particularly dangerous because WebSocket connections often bypass traditional HTTP-based access controls and firewalls that might otherwise restrict entry points based on standard web protocols, making this attack vector difficult to detect using conventional network monitoring tools unless specific behavioral anomalies are tracked.
The operational impact of this authentication bypass is severe and multifaceted, affecting confidentiality, integrity, and availability within the AI inference pipeline. First, once registered as a legitimate node, the attacker gains access to all user prompts routed through that socket. This constitutes a significant data leakage risk, exposing sensitive customer queries, proprietary business logic embedded in prompts, or potentially personally identifiable information depending on the application's usage patterns. Second, the integrity of the system is compromised because the attacker can replace legitimate nodes with their own malicious implementations. By doing so, they can intercept, modify, or poison inference results delivered to end-users, leading to misinformation or harmful outputs generated by the AI model under false pretenses. Third, availability is threatened as the attacker can trigger denial-of-service conditions by flooding the system with fake registration requests or consuming excessive resources through malicious node operations, thereby degrading service for legitimate users.
Furthermore, this vulnerability enables server-side request forgery attacks against internal network addresses. Since the PD Master trusts registered nodes to make certain types of requests on behalf of the cluster, an attacker controlling a rogue node can instruct it to issue commands or fetch data from other services within the private network that are not exposed to the public internet. This expands the attack surface significantly, allowing lateral movement into deeper layers of the infrastructure and potentially leading to further compromise of backend databases, internal APIs, or configuration management systems. The ability to manipulate traffic flow also means an attacker could perform cache poisoning attacks against model weights or prompt templates if such mechanisms are in place within the LightLLM architecture.
To mitigate this vulnerability, immediate remediation involves upgrading LightLLM to a version greater than 1.2.0 where these authentication checks have been implemented. In environments where upgrading is not immediately feasible, network-level controls should be enforced by restricting access to the /pd_register WebSocket endpoint using firewall rules or reverse proxy configurations that only allow connections from known and trusted IP ranges associated with legitimate worker nodes. Implementing mutual TLS (mTLS) for all internal cluster communications adds a robust layer of identity verification, ensuring that both parties in the connection are authenticated via certificates before any data exchange occurs. Additionally, deploying intrusion detection systems configured to monitor for unusual WebSocket traffic patterns or unexpected node registrations can provide early warning indicators of such exploitation attempts. Regular security audits focusing on API authentication mechanisms and input validation practices are essential to prevent similar flaws from persisting in distributed AI infrastructure components.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to correctly verify the identity of a user or process before granting access. It also maps to ATT&CK technique T1098, specifically SSH Account Manipulation or similar account-based manipulation tactics in distributed systems, where an attacker establishes persistent unauthorized access by impersonating legitimate entities within a trusted network zone. The exploitation path reflects CWE-20, Improper Input Validation, as the application does not adequately sanitize or validate the peer address and registration payload before processing it as a valid node entry. Addressing these root causes requires a shift towards zero-trust architecture principles for internal service-to-service communication, ensuring that no component is trusted by default regardless of its network location.