CVE-2026-93839: LightLLM Authentication Bypass Vulnerability

CVE-2026-93839 Overview

CVE-2026-93839 is an authentication bypass vulnerability affecting LightLLM through version 1.2.0. The flaw resides in the /pd_register WebSocket endpoint exposed by the PD Master component. Unauthenticated attackers can submit crafted JSON to register arbitrary nodes because the endpoint performs no peer address validation. Successful registration allows adversaries to intercept full user prompts routed to their socket, replace legitimate nodes to induce denial of service, or coerce the PD Master into issuing requests to internal network addresses. The vulnerability is tracked under CWE-306: Missing Authentication for Critical Function.

Critical Impact
Unauthenticated attackers can hijack prompt routing, disrupt inference services, and pivot to internal network resources through the PD Master.

Affected Products

LightLLM versions up to and including 1.2.0
Deployments exposing the PD Master /pd_register WebSocket endpoint
ModelTC LightLLM inference server distributions

Discovery Timeline

2026-09-18 - CVE-2026-93839 published to the National Vulnerability Database
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93839

Vulnerability Analysis

LightLLM implements a Prefill-Decode (PD) disaggregated architecture where worker nodes register with a central PD Master over a WebSocket channel. The /pd_register endpoint accepts registration payloads without authenticating the caller or validating that the peer address matches the declared node identity. Any network-reachable client can send a JSON registration message and be treated as a legitimate backend node.

Once registered, an attacker-controlled node participates in the PD Master's routing pool. User prompts and inference metadata routed to the malicious node are disclosed in plaintext to the attacker. An adversary can also overwrite the entry for an existing legitimate node, redirecting traffic or removing capacity to cause denial of service against inference workloads.

The registration data further influences downstream requests initiated by the PD Master. By supplying arbitrary host and port values, an attacker can steer the master into contacting internal network addresses, producing a server-side request forgery condition against resources not intended to be exposed externally.

Root Cause

The root cause is missing authentication and missing peer validation on a critical control-plane function. The /pd_register handler trusts self-reported node metadata and does not verify the WebSocket peer against an allow list, a shared secret, or a mutual TLS identity. See the vulnerable handlers in manager.py L691-L698 and manager.py L714-L749.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker with reachability to the PD Master's WebSocket port opens a connection to /pd_register and submits a JSON payload declaring a node role, host, and port. The PD Master accepts the registration and begins routing inference workloads to the attacker's endpoint. See the VulnCheck advisory and GitHub Issue #1576 for detailed exploitation context.

No verified public exploit code is provided; refer to the linked source snippets for the vulnerable code paths.

Detection Methods for CVE-2026-93839

Indicators of Compromise

Unexpected WebSocket connections to the /pd_register endpoint originating from IP addresses outside the trusted inference cluster subnet.
New PD Master routing entries referencing hostnames or ports not defined in the deployment inventory.
Sudden disappearance or replacement of legitimate worker nodes in PD Master registration state.
Outbound requests from the PD Master to internal RFC1918 addresses or metadata services such as 169.254.169.254.

Detection Strategies

Inspect PD Master logs for /pd_register events and correlate the source IP against the known worker inventory.
Deploy network monitoring rules that alert on WebSocket upgrade requests to the PD Master port from unauthorized sources.
Baseline the expected set of registered nodes and alert when the registry mutates outside a maintenance window.

Monitoring Recommendations

Forward PD Master and reverse proxy logs to a centralized analytics platform for continuous review of registration activity.
Enable egress flow logging on hosts running the PD Master to identify SSRF-style callbacks to internal ranges.
Track prompt-routing latency and per-node request distribution to detect sudden shifts consistent with a rogue node takeover.

How to Mitigate CVE-2026-93839

Immediate Actions Required

Restrict network access to the PD Master WebSocket port using firewall rules, security groups, or a service mesh policy so that only trusted worker hosts can reach /pd_register.
Place the PD Master behind an authenticating reverse proxy that terminates the WebSocket and enforces credentials or mutual TLS.
Audit current PD Master registration state and remove any nodes that do not match the sanctioned inventory.

Patch Information

At the time of publication, no fixed release is referenced in the NVD entry. Monitor the ModelTC LightLLM repository and GitHub Issue #1576 for an upstream fix, and upgrade beyond version 1.2.0 once a patched release becomes available.

Workarounds

Bind the PD Master listener to a loopback or private interface reachable only from trusted PD workers.
Enforce mutual TLS between PD workers and the PD Master to cryptographically validate node identity.
Deploy a network policy that denies inbound connections to the PD Master from any address outside the inference cluster CIDR.
Disable the /pd_register endpoint entirely in deployments that do not require dynamic node registration.

bash

# Example network policy restricting PD Master access to trusted subnet
iptables -A INPUT -p tcp --dport 8000 -s 10.0.10.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP