CVE-2026-90919: LightLLM Config Server RCE Vulnerability

CVE-2026-90919 Overview

CVE-2026-90919 is an unauthenticated remote code execution vulnerability in LightLLM through version 1.2.0. The flaw resides in the Config Server's /visual_register WebSocket endpoint, which passes the first client frame directly into Python's pickle.loads(). Any attacker able to reach the Config Server port can send a crafted serialized payload containing a __reduce__ method to execute arbitrary code with the privileges of the Config Server process. The vulnerability is classified under CWE-502: Deserialization of Untrusted Data and requires no authentication, no user interaction, and low attack complexity.

Critical Impact
Unauthenticated attackers with network reachability to the LightLLM Config Server can achieve full remote code execution, leading to complete compromise of the inference host and any co-located model assets.

Affected Products

LightLLM through version 1.2.0
ModelTC LightLLM Config Server component (lightllm/server/config_server/api_http.py)
Deployments exposing the LightLLM Config Server WebSocket endpoint on reachable network interfaces

Discovery Timeline

2026-09-14 - CVE-2026-90919 published to the National Vulnerability Database
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-90919

Vulnerability Analysis

LightLLM is an open-source large language model inference and serving framework maintained by ModelTC. The Config Server component exposes an HTTP and WebSocket API used to coordinate registration of visual (multimodal) workers. The /visual_register endpoint accepts a WebSocket connection and reads the first frame from the client. That frame is then handed directly to pickle.loads() without any authentication check, type validation, or sandboxing. Python's pickle module is documented as unsafe for untrusted input because a serialized object's __reduce__ method can specify an arbitrary callable and argument tuple to invoke during deserialization. Attackers exploit this by crafting a pickle payload whose __reduce__ returns a call to os.system, subprocess.Popen, or an equivalent primitive, resulting in code execution inside the Config Server process.

Root Cause

The root cause is unsafe deserialization of attacker-controlled bytes on an unauthenticated network endpoint. The vulnerable code path is documented in the LightLLM repository at api_http.py lines 79-86. No allowlist, signature verification, or safer serialization format such as JSON or msgpack is applied before the deserialization call.

Attack Vector

Exploitation requires only network access to the Config Server's listening port. The attacker opens a WebSocket connection to /visual_register and transmits a single binary frame containing a malicious pickle stream. Upon deserialization, the embedded __reduce__ gadget executes with the privileges of the Config Server process. Because LightLLM is commonly run inside GPU inference hosts, successful exploitation typically yields access to model weights, environment secrets, and adjacent workloads. Additional context is available in the VulnCheck advisory and GitHub Issue #1563.

// No verified public exploit code is included. Refer to the VulnCheck advisory
// and the referenced source lines in api_http.py for technical details.

Detection Methods for CVE-2026-90919

Indicators of Compromise

Inbound WebSocket connections to the LightLLM Config Server /visual_register path from unexpected source addresses.
Child processes spawned by the LightLLM Config Server Python process, particularly shells, curl, wget, or python -c invocations.
Outbound network connections from the Config Server host to unfamiliar IPs shortly after a /visual_register request.
New cron entries, systemd units, or SSH authorized_keys modifications on inference hosts running LightLLM.

Detection Strategies

Monitor process lineage for the LightLLM Config Server and alert on any non-Python child process.
Inspect application logs and reverse proxy access logs for requests to /visual_register from outside the trusted worker subnet.
Deploy network detection rules that flag WebSocket upgrade requests to the Config Server port containing binary payloads with the pickle opcode prefix (\\x80).

Monitoring Recommendations

Enable audit logging for file writes and process execution on hosts running LightLLM.
Forward inference server telemetry to a centralized analytics platform for behavioral baselining.
Alert on unexpected changes to LightLLM configuration files, model directories, or Python site-packages.

How to Mitigate CVE-2026-90919

Immediate Actions Required

Restrict network exposure of the LightLLM Config Server port to trusted worker nodes only, using firewall rules or a private network segment.
Take the /visual_register endpoint offline if it is not required for your deployment.
Rotate any credentials, API tokens, or model signing keys accessible from the Config Server host if exposure is suspected.
Audit inference hosts for signs of prior exploitation, including anomalous processes and outbound connections.

Patch Information

At the time of publication, LightLLM versions through 1.2.0 are affected. Track the LightLLM GitHub repository and Issue #1563 for a fixed release. Once available, upgrade to a version that replaces pickle.loads() on the /visual_register path with a safe serialization format and enforces authentication on the Config Server.

Workarounds

Bind the Config Server to 127.0.0.1 or an internal management interface unreachable from untrusted networks.
Place the Config Server behind a reverse proxy that requires mutual TLS or a shared secret before forwarding WebSocket traffic.
Run LightLLM as a low-privilege user inside a container with restricted egress and read-only model volumes to limit blast radius.
Apply an internal patch that rejects the /visual_register connection or replaces pickle.loads() with json.loads() for the initial handshake frame.

bash

# Example: restrict LightLLM Config Server exposure with iptables
# Replace 10.0.0.0/24 with your trusted worker subnet and 8080 with your Config Server port
iptables -A INPUT -p tcp --dport 8080 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -j DROP