LightLLM PD Master WebSocket Authentication Bypass

Technical Analysis

The vulnerability stems from missing peer address validation on the /pd_register WebSocket endpoint, allowing any attacker to submit crafted JSON to register malicious nodes as legitimate PD (Prefill-Decode) workers without authentication. Once registered, an attacker-controlled node can be selected by the PD Master to receive routed inference traffic, resulting in disclosure of full user prompts and potentially model outputs. Attackers can also displace legitimate compute nodes to cause denial of service, or abuse the node registration mechanism to coerce the PD Master into issuing requests to internal-only network addresses (SSRF), potentially reaching metadata services or internal management APIs. LightLLM is a high-throughput LLM inference serving framework, so this flaw directly threatens organizations running LLM-backed agents and RAG pipelines: prompt leakage from this endpoint can expose sensitive context (including embedded API keys, tool-call instructions, or proprietary retrieval data) fed to AI agents, and SSRF against internal networks could pivot into other agent orchestration or credential-management systems.

Affected Systems

LightLLM inference server versions through 1.2.0, specifically deployments exposing the PD Master /pd_register WebSocket endpoint to untrusted or public networks; affects both standalone and clustered PD (Prefill-Decode) disaggregated serving configurations.

Indicators of Compromise

• Endpoint: /pd_register
• Protocol: WebSocket (ws:// or wss://) connections to PD Master service
• Anomalous node registration requests with unvalidated peer addresses
• Unexpected outbound requests from PD Master to internal/private IP ranges

Remediation Steps

1. 1

   Upgrade LightLLM

   Update to a patched version of LightLLM beyond 1.2.0 once available from the maintainers; monitor the project's security advisories for the fix release.

2. 2

   Restrict network exposure

   Ensure the PD Master WebSocket endpoint (/pd_register) is not exposed to public or untrusted networks; restrict access via firewall rules, network segmentation, or VPN to trusted internal hosts only.

3. 3

   Implement authentication controls

   Add an authentication/authorization layer (mutual TLS, API keys, or token-based auth) in front of the PD Master registration endpoint as a compensating control if patching is not immediately possible.

4. 4

   Validate node registration

   Deploy application-layer or proxy-level peer address validation to reject node registration requests from unexpected or unverified sources.

5. 5

   Audit prompt data exposure

   Review logs for anomalous node registrations and assess whether sensitive prompts, RAG context, or embedded credentials routed through LightLLM may have been exposed; rotate any potentially leaked API keys or secrets.

6. 6

   Monitor for SSRF activity

   Inspect PD Master outbound network logs for requests to internal IP ranges, cloud metadata endpoints, or other unauthorized internal services.