External risk intelligence

LightLLM KV-transfer Remote Code Execution via Unauthenticated RPyC Control Channel

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-96560

The vulnerability exists in an RPyC control channel used for internal KV-transfer communication between workers in a LightLLM cluster. While network-reachable if misconfigured, this inter-node communication interface is typically restricted to private internal cluster networks and is not designed or intended to be exposed to the public internet in standard deployments.

Deserialization

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a critical vulnerability in LightLLM, a technology used for large language model inference. The issue allows unauthenticated attackers to execute arbitrary code remotely by sending specially crafted data over an exposed control channel, potentially compromising the integrity and availability of services relying on this technology. The main concern is confirming relevance and exposure.

Unauthenticated remote code execution in LightLLM.
Critical vulnerability in language model inference.
Confirm relevance and exposure to affected systems.

Attack Path

How an attacker could exploit the issue

An attacker can reach the vulnerable component over the network without needing any authentication. When the LightLLM KV-transfer worker is initiated with specific parameters, it exposes a control channel. By sending specially crafted data to this channel, an attacker can trigger the vulnerability. Successful exploitation allows arbitrary code execution with the same permissions as the LightLLM service.

No authentication required for access.
Malicious data sent to RPyC control channel.
Arbitrary code execution with service privileges.

Live Threat

Current exploitation, exposure, and threat context

A critical vulnerability in LightLLM's KV-transfer worker could allow an unauthenticated attacker to execute arbitrary code. This occurs when the service is started with a specific mode that exposes a control channel, which then deserializes malicious data. The attacker could leverage this to run commands with the same permissions as the LightLLM service.

System data and service behavior at risk.
Exposure via unauthenticated control channel.
Arbitrary code execution possible.

Operational Fix

Recommended remediation, mitigation, and detection steps

Given the nature of the vulnerability in LightLLM's KV-transfer worker, application owners and infrastructure teams are most likely responsible for addressing this critical risk. The immediate first step is to locate all instances of the affected technology, determine their exposure and business criticality, and then identify the specific accountable teams or individuals. This foundational understanding will enable a targeted remediation plan based on the assessed risk.

Confirm responsible application and infrastructure teams.
Verify affected technology deployment and exposure.
Plan remediation based on identified risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is LightLLM?

LightLLM is a high-performance framework designed for serving large language models. It optimizes inference tasks by efficiently handling model memory and computations. The software uses specific components, such as the KV-transfer worker, to manage the movement of key-value caches between processing nodes during distributed operations.

How does CVE-2026-96560 result in code execution?

This vulnerability is classified as CWE-502, which involves insecure deserialization. The affected LightLLM component automatically trusts and processes incoming data objects without verification. An attacker can send a malicious, serialized object that, when deserialized by the service, forces the system to execute unintended commands.

When is the KV-transfer worker vulnerable?

The risk is active only when the KV-transfer worker is started using the '--pd_trans_mode nccl' configuration flag. This specific setting initiates an RPyC control channel. If this mode is not enabled or if the service is running with different configuration parameters, this particular path for remote code execution is not present.

Is my LightLLM deployment reachable by attackers?

Halo Surface Signal indicates that while this channel is network-reachable, it is designed for internal cluster communication between workers. It is unlikely to be exposed to the public internet in standard setups. You should verify if your internal network architecture allows unauthorized connections to these specific node-to-node ports.

How do I respond to this LightLLM vulnerability?

Start by auditing your infrastructure to identify all running instances of LightLLM and determine which are launched with the '--pd_trans_mode nccl' flag. Once identified, evaluate the network accessibility of these nodes. Prioritize restricting access to the RPyC control channel so that it is only reachable by trusted internal system components.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.