LMDeploy 0.9.0〜0.18.0 の /update_weights が pickle を逆シリアル化し、認証なしでコマンドを実行される（CVE-2026-119706）: 修正版は未公開、修正の PR は未マージ

推論サーバー LMDeploy（InternLM）の 0.9.0 から 0.18.0 までで、api_server の POST /update_weights エンドポイントが、リクエストに含まれる base64 文字列を ForkingPickler.loads で逆シリアル化する不具合（CVE-2026-119706、CWE-502）が 10/30 に NVD へ公開されました。細工した pickle を送ると、api_server プロセスの権限で OS コマンドを実行できます。認証は不要で、CVSS は v3.1 が 9.8、v4.0 が 9.3 の Critical です（どちらも CNA の値）。10/31 時点で修正版のリリースはなく、修正の PR（#4964）も未マージです。 最新リリースは 0.18.0（9/28）で、対象範囲の上限と同じです。

何が起きるか

• /update_weights は、リクエストの serialized_named_tensors を文字列・リスト・辞書のいずれかで受け取り、そのまま重みの更新処理に渡します。文字列のとき、TurboMind バックエンドと PyTorch バックエンドの双方で、base64 を復号した内容が ForkingPickler.loads に渡されます。pickle は読み込み時に任意の呼び出しを実行できる形式で、重みの形や型を確かめる前にこの処理が走ります。
• 公開された課題（#4698）によると、lmdeploy serve api_server は既定で 0.0.0.0 に待ち受け、api_keys は未設定が既定で、認証のミドルウェアは API キーを設定したときだけ入ります。既定のまま公開した場合、到達できる相手は誰でもコマンドを実行できると、課題と NVD は述べています。
• 当サイトでは、v0.18.0 の turbomind.py 345 行目に ForkingPickler.loads(pybase64.b64decode(request.serialized_named_tensors)) があること、main ブランチ（10/31 に確認）にも同じ行が残り、management.py の /update_weights が検証なしでエンジンへ渡していることをソースで確認しました。実際に送信しての再現はしていません。
• 悪用の報告は確認できていません。CISA の KEV には載っていません（2026.10.30 版の一覧で確認）。課題には再現用のコードが載っていますが、当サイトでは実行していません。

影響を受ける条件

項目	内容
対象	InternLM LMDeploy 0.9.0 〜 0.18.0（NVD の記載）。GitHub の勧告（GHSA-fq46-3gxq-v4vc）は NVD の説明文をそのまま載せ、パッケージ・版の範囲は構造化されていない
前提	api_server のポートに到達できること。API キー未設定（既定）なら認証は不要
評価	CVSS v3.1 は 9.8（Critical、AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）、v4.0 は 9.3。値は CNA の VulnCheck が付けたもので、NVD 自身の評価ではない。NVD の状態は「Deferred」（10/31 時点）
弱点の分類	CWE-502（信頼できないデータの逆シリアル化）
修正版	なし（最新は 0.18.0、9/28 公開）

修正の状況

• 修正の PR は #4964「[Fix] Reject pickle on HTTP /update_weights」で、9/14 に作成され、10/31 時点で未マージです（最終更新は 9/17、マージ可否の状態は blocked）。課題 #4698（6/22 作成）も開いたままです。
• PR の説明によると、HTTP の /update_weights は既定で pickle を拒否し、環境変数 LMDEPLOY_ALLOW_PICKLE_UPDATE_PARAMS=1 を設定したときだけ、信頼できる同一ノード内の XTuner CUDA IPC の用途に限って従来の動作に戻ります。HTTP 側は引き続き pickle.loads を呼びません。代わりに load_format="safetensors" か、{dtype, shape, data} の辞書による受け渡しを使えるようにします。
• この変更は互換性を壊します。pickle を送っている既存のクライアントは、サーバー側で環境変数を設定しない限り HTTP 400 になります。
• PR は未マージのため、PR の内容どおりの修正がリリースに入るかは確認できていません。

対応

1. 0.18.0 以下を使っている場合、api_server を信頼できないネットワークへ公開していないか確認します。既定の 0.0.0.0 のまま公開していると、到達できる相手は誰でも対象です。
2. 修正版が出るまでの当面の対策として、ポートを内部ネットワークに限定する、リバースプロキシなどで /update_weights へのアクセスを遮断する、--server-name を 127.0.0.1 にする、--api-keys を設定する、といった方法が考えられます（本記事の推定で、効果は検証していません）。なお API キーの設定が /update_weights にも効くかは、当サイトでは確認していません。
3. 重みの更新機能を使っていない運用では、このエンドポイントを外部から使えない状態にしておきます（本記事の推定）。
4. 修正版の公開、または #4964 のマージを監視します。main から直接ビルドして使っている場合は、マージ後の版へ更新します。

未確認の点

• 悪用の報告は確認できていません。KEV にも載っていません。
• NVD の評価は未実施（状態は Deferred）で、CVSS は CNA（VulnCheck）の値です。
• EPSS は 1.03%（10/31 時点、パーセンタイル 63.7%）です。
• 当サイトでは、実際のリクエスト送信による再現をしていません。コードの該当行の存在のみを確認しています。
• 0.9.0 より前の版が対象かは確認できていません。また、API キーを設定した環境で /update_weights が保護されるかも確認していません。
• 修正版の公開時期は不明です。
• 日付は、NVD の公開（2026-10-30 16:17 UTC）、GitHub の課題・PR・リリースの記録に基づきます。