Remote code execution vulnerability disclosed in LightLLM’s NCCL control channel

An unauthenticated remote code execution vulnerability, tracked as CVE-2026-96560, has been disclosed in LightLLM’s NCCL-based disaggregated prefill/decode deployments. A researcher submitted reproduction details on September 22, and VulnCheck published an advisory the following day. The GitHub Advisory Database lists a CVSS 4.0 score of 9.3, with patched versions still marked as unknown. [Original report](https://github.com/ModelTC/LightLLM/issues/1590), [vulnerability advisory](https://github.com/advisories/GHSA-849v-g89f-q67r)

The conditions for exposure are specific: nodes must enable KV cache transfer with `--pd_trans_mode nccl`, and an attacker must be able to reach the worker process’s RPyC control port. The advisory covers versions through 1.2.0; this does not imply that every LightLLM deployment exposes the same entry point. Both the [VulnCheck advisory](https://www.vulncheck.com/advisories/lightllm-through-1.2.0-unauthenticated-remote-code-execution-via-nccl-pd-rpyc-control-channel) and the original report limit the issue to this transfer path.

Inspection of the 1.2.0 source code shows that the control service enables pickle and permissive attribute access without configuring authentication when creating the server. Incoming notifications are also passed to `pickle.loads`. The type assertion occurs after deserialization, so it cannot prevent code execution that has already occurred during deserialization. This turns a channel intended to exchange node coordination information into an entry point where untrusted input can trigger code execution. [Control channel source code](https://github.com/ModelTC/lightllm/blob/v1.2.0/lightllm/server/router/model_infer/mode_backend/pd/nccl_kv_transporter.py)

A deployment blind spot is the listening address: the code first uses `get_hostname_ip()` and falls back to `args.host` only if that fails. Changing the HTTP service’s address therefore does not guarantee that the control channel is also restricted. The direct engineering implication is that adding authentication only at the API frontend is insufficient to protect this entry point; teams must separately check the actual listening address and network rules between nodes. [Transporter source code](https://github.com/ModelTC/lightllm/blob/v1.2.0/lightllm/server/router/model_infer/mode_backend/pd/kv_transporter.py)

The reporter states that testing across hosts achieved code execution with the service account’s privileges, while health checks continued to report normal status after exploitation. These are results from a public reproduction, not evidence of exploitation in the wild or proof that the issue can be reproduced in every environment. [Test records](https://github.com/ModelTC/LightLLM/issues/1590)

For monitoring design, this means that “the service can still respond to inference requests” and “the control channel has not been compromised” require separate verification. Because the code executes inside the worker process, the actual impact also depends on the service account’s privileges and the caches and files that the process can read. The test machine’s permission configuration cannot be assumed to apply to other clusters.

The official RPyC documentation recommends restricting services to trusted networks and avoiding excessive object exposure. Affected teams can start by restricting which sources may connect to the control port and tracking fixes for channel authentication, safe serialization formats, and explicit bind addresses. Changing a protocol flag alone still requires checking deserialization calls within the application. [RPyC security documentation](https://rpyc.readthedocs.io/en/latest/docs/security.html)