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)