GitHub Issue #1563

The /visual_register WebSocket endpoint in LightLLM Config Server contains an unauthenticated unsafe deserialization vulnerability (CWE-502). The endpoint directly invokes pickle.loads() to parse visual service registration data provided by a client. Because no authentication check occurs before deserialization, this can lead to arbitrary code execution with the privileges of the Config Server process.

The vulnerability is triggered while the registration object is parsed and does not require the client to complete a valid registration. Both the unauthenticated test case and the invalid-credential test case recorded code execution within the Config Server process. This report includes the affected code, test environment, key output, result file information, and process-attribution evidence.

Exploitation requires access to this control-plane service. Network-reachable deployments may be exposed to unauthenticated remote code execution.

Affected Component and Code

Vulnerability Mechanism

Config Server uses a separate ASGI application to handle service registration. After accepting a connection, visual_websocket_endpoint directly deserializes network input, then accesses object attributes and updates the visual service registry. The relevant code is as follows:

Source code at the specified commit, lines 78–86 .

pickle can execute object-reconstruction logic while restoring Python objects and must therefore not be used directly to parse untrusted network data. Before this operation, the handler neither establishes the sender's identity nor restricts the input to ordinary data that has undergone structural validation. The VIT_Obj type annotation does not provide runtime security validation, and subsequent registry updates or exception handling cannot prevent execution that has already occurred during deserialization.

The security issue arises at the trust boundary where client-supplied registration input enters the execution context of the service process, independently of whether registration ultimately completes.

Step 1: Inspect the Affected Code

Demonstrates: No identity authentication occurs before await websocket.accept() on line 80, and line 83 passes the first binary WebSocket frame directly to pickle.loads() .

Step 2: Send the Payload Directly with Python

Observed result (when run inside the Config Server container):

Demonstrates: The client sends only one pickle payload frame; the server receives and executes the deserialization without authentication. marker exists: True indicates that the exec code embedded in the payload was executed by the server process and performed the file-write operation.

Step 3: Read the Marker File and Confirm That It Was Written by the Config Server Process

Demonstrates (the central step in the mechanism analysis):

The marker file was created by the hypercorn process in the Config Server container, with PID 166 and an argv value containing --bind 127.0.0.1:60088 . The combined process fields—PID, argv, and hostname—show that the exec call was executed in the Config Server process rather than merely by the test client.

Step 4: Inspect Server Logs to Confirm the Event Sequence

Demonstrates: The received registered_visual_server_obj message is logged by api_http.py:84 after pickle.loads() succeeds. Together with the marker-file evidence, the log confirms that the server process processed the payload rather than merely accepting the connection.

The vulnerability allows an unauthenticated client that can access the endpoint to obtain code execution with the privileges of the Config Server process. This can affect resources accessible to that process:

Confidentiality: Read service configuration, environment information, and files available to the service account.

Integrity: Modify writable process data, service configuration, or in-memory registration state, compromising the integrity of service coordination information.

Availability: Disrupt or terminate Config Server, affecting service discovery and coordination functions that depend on the component.

The execution account recorded in this test was uid=0 , which corresponds to root privileges within the tested container. Effective privileges in other deployments depend on the Config Server account and its isolation configuration.

Replace the visual service registration protocol with a data-only serialization format such as JSON; enforce field, type, and length validation; authenticate service identities before parsing registration data; and update legitimate clients accordingly. Compared with the PD Master endpoints described in the original CVE-2026-26220 report , this issue is located in the /visual_register handler of the separate Config Server application. The issues the same weakness class but involve different registration handlers; remediation must explicitly cover this handler and its associated communication protocol.