LMCacheに深刻なRCE脆弱性、未修正のままPoCエクスプロイトが公開

LMCacheに存在する深刻な脆弱性により、認証されていない攻撃者が、到達可能なマルチプロセス構成のデプロイメントに対して任意のコードを実行できる恐れがあります。原因は、安全でないPythonのpickleデシリアライズを悪用できる点にあります。

この脆弱性は「CVE-2026-105192」として追跡されており、CVSSスコアは9.8です。JFrogは2026年10月7日にセキュリティアドバイザリと実証コード(PoC)を公開しました。同日時点で修正版はリリースされていないとしています。

脆弱性を発見したのはJFrog Security Researchチームのユヴァル・モラヴチック(Yuval Moravchick)氏で、アドバイザリID「JFSA-2026-001694382」として文書化されています。

Securityincident response

脆弱なデコード処理はバージョン0.3.9で初めて登場しました。バージョン0.5.5のほか、0.5.6rc3までのすべてのリリース候補、および10月7日に確認された開発ブランチにも残っています。

LMCacheのRCE脆弱性

LMCacheのマルチプロセスモード(分散モードとも呼ばれます)は、ZeroMQのROUTERソケットを開きます。ワーカープロセスはこのソケットを通じて登録を行い、キーバリューのキャッシュブロックを共有します。

このトランスポートは同じLMCacheのプロセス間での利用を想定していますが、認証の仕組み(CURVE、ZAP、パスワード保護など)がありません。そのため、到達可能なインスタンスは信頼できないメッセージを受け付けてしまいます。

このトランスポートは、デフォルトではlocalhostを使用します。ただし、運用者が`–host`オプションでルーティング可能なアドレスを指定すると、ノード間の接続が可能になります。

JFrogは、9.8という深刻なスコアが当てはまるのは、このネットワークから到達可能な構成に限られると強調しています。他のマシンからアクセスできないデフォルトの単一ホスト構成は対象外です。また、vLLMプロセス内だけでLMCacheを実行している場合、影響を受けるポートは開きません。

受信メッセージにはMessagePackが使われ、拡張コード1がDeviceIPCWrapperに対応付けられています。デコード時には、`lmcache/v1/multiprocess/custom_types.py`の拡張フックが埋め込まれたデータを`lmcache/v1/platform/base/ipc_wrapper.py`の`DeviceIPCWrapper.Deserialize`に渡します。この関数が`pickle.loads`を呼び出すため、攻撃者が細工したシリアライズ済みオブジェクトでコードを実行させることが可能です。

重要なのは、デシリアライズがサーバーによるREGISTER_KV_CACHAの引数処理の最中、つまりリクエストハンドラーが実行される前に行われる点です。このため、後続の引数チェックやハンドラーのエラーでは、デコード中に実行されたコードを止められません。

JFrogが公開したデモでは、細工したマルチパートメッセージをZeroMQのDEALERソケットから、トランスポートのデフォルトポートである5555に送信します。キャッシュのペイロードには、悪意あるpickleオブジェクトを含むMessagePack拡張が入っています。このオブジェクトは再構築の過程でOSコマンドを実行します。

デモでは`id`コマンドの出力が`/tmp/zmq_pwn`に書き込まれ、LMCacheプロセスのアカウント権限でコードが実行されたことが確認できます。公式コンテナイメージではこのプロセスがrootで動作しているため、コンテナ内でroot権限による実行が可能です。ただし、基盤となるホストへのエスケープを示したものではありません。

実行後、ハンドラーが期待するラッパーオブジェクトの代わりにコマンドの戻り値を受け取るため、サーバーは型エラーをログに記録します。しかし、このエラーが出る時点では、すでに攻撃を防ぐには遅すぎます。

JFrogは、ネットワーク経由のpickleデシリアライズを安全なシリアライズ形式に置き換えることを推奨しています。あわせて、CURVEやメッセージ単位のHMAC検証といった方法でZeroMQトランスポートを認証するよう勧めています。認証が設定されていない限り、ルーティング可能なアドレスへのバインドは禁止すべきだとしています。

これらの対策が実施されるまでの間、運用者はルーティング可能な`–host`設定の使用を避け、可能な限りlocalhostへのバインドを維持してください。必要なクラスターへのアクセスは、ファイアウォールのルールで制限することも重要です。ネットワークの分離で露出を抑えることはできますが、脆弱性そのものは解消されません。脆弱なトランスポートに接続できるシステムであれば、LMCacheプロセスの権限でコードを実行できる状態は変わらないためです。

サイバー脅威を被害が出る前に阻止し、MTTRを21分短縮。ANYRUNのSandboxをSOCに導入

翻訳元: https://gbhackers.com/critical-lmcache-rce-vulnerability/

本記事は gbhackers.com の記事を翻訳・要約したものです。