CVE-2026-26220: LightLLM RCE Vulnerability

CVE-2026-26220 Overview

CVE-2026-26220 is a critical insecure deserialization vulnerability affecting LightLLM version 1.1.0 and prior. The vulnerability exists in the PD (prefill-decode) disaggregation mode, where the PD master node exposes WebSocket endpoints that receive binary frames and pass the data directly to pickle.loads() without authentication or validation. A remote attacker who can reach the PD master can send a crafted payload to achieve arbitrary code execution on the vulnerable system.

Critical Impact

This vulnerability allows unauthenticated remote code execution, enabling attackers to fully compromise systems running LightLLM in PD disaggregation mode without any prior authentication or user interaction.

Affected Products

• LightLLM version 1.1.0
• LightLLM all versions prior to 1.1.0
• Systems running LightLLM in PD (prefill-decode) disaggregation mode

Discovery Timeline

• 2026-02-17 - CVE-2026-26220 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2026-26220

Vulnerability Analysis

This vulnerability falls under CWE-502 (Deserialization of Untrusted Data). The core issue stems from the unsafe use of Python's pickle module to deserialize data received over WebSocket connections. Python's pickle module is known to be insecure when used with untrusted data, as it can execute arbitrary code during the deserialization process.

The vulnerability is particularly severe because it requires no authentication and can be exploited remotely over the network. When LightLLM operates in PD disaggregation mode, the master node accepts incoming WebSocket connections and processes binary frames without verifying the source or validating the content. The received data is passed directly to pickle.loads(), which will execute any embedded code payloads.

An attacker can craft a malicious pickle payload that, when deserialized, executes arbitrary system commands. This could lead to complete system compromise, data exfiltration, lateral movement within the network, or deployment of additional malicious payloads.

Root Cause

The root cause of this vulnerability is the direct use of pickle.loads() on untrusted input received from WebSocket binary frames in the PD master node's API handler. The affected code paths are located in lightllm/server/api_http.py at lines 310 and 331, where incoming data is deserialized without any authentication checks or content validation.

Python's pickle module documentation explicitly warns against using it with untrusted data, as pickle can execute arbitrary Python code during deserialization. The absence of authentication on the WebSocket endpoints compounds this issue, allowing any network-accessible attacker to exploit the vulnerability.

Attack Vector

The attack vector is network-based, requiring no privileges or user interaction. An attacker who can reach the PD master node's WebSocket endpoints can exploit this vulnerability by:

1. Establishing a WebSocket connection to the vulnerable PD master node
2. Crafting a malicious pickle payload containing code to be executed
3. Sending the payload as a binary frame to the WebSocket endpoint
4. The server deserializes the payload using pickle.loads(), executing the embedded malicious code

The attack can be carried out remotely over the network. The vulnerability is documented in detail in the ChocaPikk RCE Analysis and the VulnCheck Security Advisory.

Detection Methods for CVE-2026-26220

Indicators of Compromise

• Unexpected WebSocket connections to the LightLLM PD master node from unknown or external IP addresses
• Anomalous process spawning or command execution originating from the LightLLM Python process
• Unusual network traffic patterns indicating data exfiltration or reverse shell connections
• Modifications to system files or new file creation in unexpected locations by the LightLLM service account

Detection Strategies

• Monitor WebSocket traffic to LightLLM PD master nodes for suspicious binary frame payloads containing pickle magic bytes (\\x80\\x04\\x95 for protocol 4)
• Implement network segmentation and alert on any external access attempts to PD master node endpoints
• Deploy endpoint detection to identify Python process spawning unexpected child processes such as shells or network utilities
• Review application logs for deserialization errors or unusual activity patterns around the WebSocket handlers

Monitoring Recommendations

• Enable verbose logging on LightLLM instances and forward logs to a centralized SIEM for analysis
• Implement network intrusion detection rules to identify pickle-based exploitation attempts in WebSocket traffic
• Monitor for behavioral anomalies in processes spawned by the LightLLM service, particularly command interpreters or network tools
• Set up alerts for new outbound connections from LightLLM servers to unknown destinations

How to Mitigate CVE-2026-26220

Immediate Actions Required

• Disable PD disaggregation mode if not required for operations until a patch is available
• Implement network-level access controls to restrict access to the PD master node's WebSocket endpoints to trusted internal systems only
• Place LightLLM instances behind a firewall or VPN that requires authentication before allowing access to WebSocket endpoints
• Audit existing LightLLM deployments for signs of compromise using the indicators listed above

Patch Information

As of the last update on 2026-02-18, no official patch has been released by the LightLLM maintainers. Organizations should monitor the GitHub Issue #1213 for updates on the vulnerability fix and apply patches as soon as they become available.

The vulnerable code is located in the api_http.py file within the LightLLM repository. A proper fix should replace the unsafe pickle.loads() calls with a secure serialization format such as JSON, or implement strict validation and authentication on the WebSocket endpoints.

Workarounds

• Implement network segmentation to isolate LightLLM PD master nodes from untrusted networks and limit access to authorized internal systems only
• Deploy a reverse proxy with authentication in front of the WebSocket endpoints to prevent unauthenticated access
• If possible, avoid using PD disaggregation mode and run LightLLM in standard mode until a security patch is released
• Consider implementing application-level firewall rules to block incoming WebSocket connections containing pickle serialization patterns

Organizations should consult the LightLLM Documentation for guidance on alternative deployment configurations that do not expose the vulnerable PD mode endpoints.