LightLLM NCCL 控制通道揭露遠端程式碼執行漏洞

LightLLM 的 NCCL 預填充／解碼分離部署被揭露未驗證遠端程式碼執行漏洞，編號為 CVE-2026-96560。研究者於 9 月 22 日提交重現紀錄，VulnCheck 隔日列入公告；GitHub 漏洞資料庫列出的 CVSS 4.0 分數為 9.3，修補版本仍標示未知。[原始回報](https://github.com/ModelTC/LightLLM/issues/1590)、[漏洞公告](https://github.com/advisories/GHSA-849v-g89f-q67r)

影響條件相當具體：節點須以 `--pd_trans_mode nccl` 啟用 KV 快取傳輸，而且攻擊者能連到工作程序的 RPyC 控制埠。公告描述涵蓋至 1.2.0；不能據此推定所有 LightLLM 部署都暴露相同入口。[VulnCheck 公告](https://www.vulncheck.com/advisories/lightllm-through-1.2.0-unauthenticated-remote-code-execution-via-nccl-pd-rpyc-control-channel)與原始回報均將問題限定在這條傳輸路徑。

核對 1.2.0 原始碼可見，控制服務開啟了 pickle 與寬鬆屬性存取，沒有在建立伺服器時設定驗證。收到的通知還會交給 `pickle.loads`，型別斷言位於反序列化之後，無法阻止反序列化階段已發生的程式執行。這使本應交換節點協調資訊的通道，成為可執行不可信輸入的入口。[控制通道原始碼](https://github.com/ModelTC/lightllm/blob/v1.2.0/lightllm/server/router/model_infer/mode_backend/pd/nccl_kv_transporter.py)

部署上的盲點是監聽位址：程式優先採用 `get_hostname_ip()`，失敗才使用 `args.host`，因此調整 HTTP 服務的位址不保證同時限制控制通道。工程上的直接推論是，僅在 API 前端加上驗證仍不足以涵蓋這個入口，必須另查實際監聽位址與節點間網路規則。[傳輸器原始碼](https://github.com/ModelTC/lightllm/blob/v1.2.0/lightllm/server/router/model_infer/mode_backend/pd/kv_transporter.py)

回報者稱，跨主機測試取得了服務帳號權限，且利用後健康檢查仍回報正常。這是公開重現結果，尚不能當成已發生在野攻擊或所有環境都能重現的證據。[測試紀錄](https://github.com/ModelTC/LightLLM/issues/1590)

就監控設計而言，這意味著「仍能回覆推論請求」與「控制通道未遭入侵」需要分開驗證。由於程式在工作程序內執行，實際危害也取決於服務帳號權限，以及該程序可讀取的快取與檔案；不能將測試機的權限配置直接套用到其他叢集。

RPyC 官方文件建議將服務限制在可信網路，避免過度暴露物件。受影響團隊可先限制控制埠的來源，並追蹤通道驗證、安全序列化格式與明確綁定位址的修補；單改協定開關，仍須檢查應用程式內的反序列化呼叫。[RPyC 安全文件](https://rpyc.readthedocs.io/en/latest/docs/security.html)