LMCacheに深刻な脆弱性が見つかりました。悪用されると、認証なしのリモートの攻撃者が、公開状態にある分散環境で任意のコードを実行できる恐れがあります。root権限で実行される可能性もあります。
この脆弱性は「CVE-2026-105192」として追跡されており、CVSSスコアは9.8です。原因は、LMCacheのマルチプロセス用ZeroMQトランスポートにおける、Python pickleの安全でないデシリアライズです。
問題を発見して報告したのは、JFrogのセキュリティ研究者Yuval Moravchick氏です。管理番号はJFSA-2026-001694382です。
影響を受けるのは、LMCacheのバージョン0.3.9以降です。PyPIの最新リリースであるバージョン0.5.5、バージョン0.5.6のリリース候補（0.5.6rc3まで）、および2026年10月7日時点の開発ブランチが含まれます。
LMCacheは、大規模言語モデルの推論環境でキー・バリューキャッシュのブロックを共有、再利用するために使われます。マルチプロセス（分散）モードでは、ZeroMQのROUTERソケットを公開します。ワーカープロセスはこのソケットを通じて登録を行い、キャッシュ関連のデータをやり取りします。
このインターフェースは、信頼できる同種のLMCacheプロセス同士が通信することを前提に設計されています。しかしJFrogによると、トランスポート認証、メッセージ認証、パスワード、CURVE暗号化、ZeroMQ認証プロトコル（ZAP）による制御のいずれも実装されていません。
危険な状態になるのは、運用者が--hostパラメータを使い、マルチプロセスのLMCacheをルーティング可能なネットワークインターフェースにバインドした場合です。
マルチノード構成では、リモートのピアがサービスと通信できるようになります。通信には通常、TCPポート5555が使われます。このポートに到達できる攻撃者は、認証を経ずに細工したZeroMQ DEALERメッセージを送信できます。
攻撃では、LMCacheのDeviceIPCWrapperオブジェクト向けに登録されたmsgpack拡張ハンドラが悪用されます。REGISTER_KV_CACHEリクエストの引数をデコードする際、LMCacheはDeviceIPCWrapper.Deserializeを呼び出します。このメソッドは、攻撃者が制御するデータに対してPythonのpickle.loadsを実行します。
Pythonのpickleは、信頼できない入力に使うには安全でない形式です。悪意あるオブジェクトをデシリアライズすると、関数やコマンドが実行される恐れがあるためです。重要なのは、このデシリアライズがサーバーのリクエストハンドラによるオブジェクトの検証や登録処理より前に行われる点です。
JFrogは、悪意あるメッセージ1通だけで、引数のデコード中にコマンドを実行できることを実証しました。リクエストが想定ハンドラの形式に合わないため、影響を受けるサーバーは後から型エラーを報告する場合があります。ただし、このエラーが出るのは埋め込まれたコマンドの実行後です。
そのため、通常のアプリケーションレベルの検証は、セキュリティ対策として機能しません。影響の大きさは、デプロイ構成に大きく左右されます。トランスポートをlocalhostにバインドしたままの標準的な単一ホスト構成は、他のマシンから到達できません。
一方、ルーティング可能なアドレスでマルチノード用に構成したシステムは、ネットワーク制御でアクセスを防いでいない限り、リモートからの悪用にさらされます。
公式のコンテナ構成ではLMCacheのプロセスがrootで動作するため、リスクは特に深刻です。この場合、攻撃が成功すると、コンテナ内でroot権限のコード実行を許してしまいます。
管理者は、マルチプロセスモードで動作しているLMCacheインスタンスをただちに洗い出してください。そのうえで、ポート5555が、信頼できるローカルインターフェースや厳格に管理されたクラスターネットワークの外に公開されていないかを確認する必要があります。
パッチが公開されるまでの間、運用者は次の対策を取るべきです。サービスをルーティング可能なアドレスにバインドしない、ファイアウォールルールやネットワーク分離でアクセスを制限する、可能であればプロセスをrootで実行しない、の3点です。
恒久的な対策としては、ネットワーク上のピアから受信したデータに対するpickle.loadsの使用をなくす必要があります。シリアライズの仕組みも、スキーマ検証を備えた安全な形式に置き換えなければなりません。
JFrogはさらに、CURVEやメッセージごとのHMAC検証などでZeroMQ接続を認証することを推奨しています。認証が明示的に設定されていない限り、ルーティング可能なアドレスへのバインドを禁止することも求めています。
これらの対策が必要なのは、ファイアウォールが制限できるのは、攻撃を試みられるホストの範囲だけだからです。認証のないポートに接続できるシステムであれば、LMCacheのサービスアカウントとしてコードを実行できる可能性が残ります。
脅威調査を効率化し、手作業を減らすために、16,000以上のSOCチームがANY.RUNを利用しています。チームで試してみる
翻訳元: https://cyberpress.org/critical-lmcache-vulnerability/
