GitHub Advisory Databaseに、LMCacheのマルチプロセスモードで任意のコードを実行される脆弱性「CVE-2026-105192」が掲載されています。修正版は0.5.6で、通信形式の変更に伴い、全ワーカーとサーバーを同時に更新する必要があります。資料にはアドバイザリーの公開日は記載されていません。
深刻度9.8は、通信口に外部から届く構成が前提
対象は、分散モードとも呼ばれるマルチプロセスモードです。このモードは、キャッシュを共有するために、認証のないZeroMQの通信口を開きます。既定のポート番号は5555です。
問題は、受信したデバイスIPC情報を、Pythonの「pickle.loads」で逆直列化する処理にあります。逆直列化とは、受け取ったデータをプログラムで扱う形式に戻すことです。アドバイザリーによると、この通信口に細工したメッセージが1件届くだけで、LMCacheプロセスの実行ユーザー権限でコードが動く恐れがあります。
ただし、既定の待ち受け先は、そのマシン内からだけ接続できるlocalhostです。他のマシンからは到達できません。深刻度スコア9.8は、外部から到達できるアドレスで待ち受ける構成を前提としています。複数ノード構成では「--host」で外部から到達可能なアドレスを指定するため、実際の設定確認が重要です。
修正版は0.5.6、更新は全体をそろえる
影響するリリースは0.3.9から0.5.5です。0.5.6のリリース候補版と、修正PR #5644より前の開発ブランチのビルドも対象です。リリース候補版を、修正済みの正式版と取り違えないようにしてください。
0.5.6はpickleを廃し、使用前に検証する型付きのMessagePack形式へ変更しました。修正対象はZeroMQとgRPCの両方の通信経路です。通信形式が変わるため、一部だけを先に更新するのではなく、全ワーカーとサーバーの同時更新を計画する必要があります。
従来のKubernetes配備例は全てのネットワークインターフェースで待ち受け、公式コンテナイメージはroot権限で実行する構成でした。0.5.6では、配備例の待ち受け先がlocalhostに、公式イメージの実行ユーザーが非rootに変更されています。
日本での提供は発表には書かれていません。
影響する会社・しない会社
- 影響する: 対象版のLMCacheをマルチプロセスモードで使う会社です。localhostでの待ち受けでも、対象版であること自体は変わりません。
- 影響する: 複数ノード構成などで通信口を外部から到達可能にしている会社です。信頼できないネットワークへの公開歴がある場合は、更新だけでなく侵害の可能性を前提とした確認も必要です。
- 影響しない: vLLMプロセス内だけでLMCacheを使う構成では、問題の通信ポートは開きません。今回の通信口を通じた攻撃条件とは区別できます。
- 影響しない: 修正版0.5.6へ全ワーカーとサーバーを更新した構成は、今回の修正対象となる問題への対応済みです。
情シスが今日やること
- 今日中に、AI基盤の運用担当へ利用構成を照会します。 LMCacheの版、マルチプロセスモードの使用有無、開発版ならPR #5644の修正を含むかを確認します。情シスだけで判別できない場合は、この3点を開発担当や運用委託先に渡してください。
- 起動設定と配備定義で、通信口の公開範囲を確認します。 「--host」の指定、実際の待ち受けアドレスとポート番号を見ます。既定は5555ですが、実設定を基準に、ファイアウォールやKubernetesのネットワークポリシーも確認します。更新まではlocalhostか信頼できるクラスターネットワークに限定し、非root実行も検討します。
- 運用担当と、全体を同時更新する作業日時を決めます。 対象は全ワーカーとサーバーです。0.5.6のリリース候補版ではなく、修正済みの0.5.6を指定します。更新期限は資料に記載されていないため、自社の公開状況を踏まえて作業日を決めてください。
- 信頼できないネットワークへの公開歴があれば、今日中にセキュリティ担当へ共有します。 アドバイザリーは、接続履歴、不審なプロセス、LMCacheからの外向き通信の確認を勧告しています。到達可能だった認証情報の更新と、クリーンなイメージからの再配備も対応計画に含めます。
