LMCacheに未修正の重大な脆弱性、リモートコード実行が可能

セキュリティ研究者が、vLLMなどの大規模言語モデル（LLM）サーバー向けのオープンソース高速化レイヤーであるLMCacheにおける重大な脆弱性を特定しました。JFrogによって10月7日に公開されたこの欠陥は、認証されていない攻撃者が影響を受けるシステム上で任意のコードを実行することを可能にします。執筆時点では修正版ソフトウェアは提供されておらず、運用者は保護のためにネットワーク設定の変更を余儀なくされています。

何が起きたか

CVE-2026-105192として追跡されているこの脆弱性は、深刻度スコア10段階中9.8と評価されています。2025年10月にリリースされたLMCacheバージョン0.3.9から、最新の安定版リリース0.5.5までが影響を受けます。また、0.5.6のリリース候補および現在の開発ブランチでも問題が残存しています。Yuval Moravchick率いるJFrogのセキュリティ研究チームは、細工された単一のネットワークメッセージがキャッシュサーバー上のリモートコード実行を引き起こす可能性があることを発見しました。

リスクレベルはデプロイメント構成に大きく依存します。デフォルトでは、LMCacheマルチプロセスサーバーはローカルマシンでのみリッスンするため、外部からのアクセスは防止されます。しかし、多くのマルチノードデプロイメントでは、マシン間でキャッシュデータを共有するために、サーバーがルーティング可能なアドレスでリッスンする必要があります。LMCache自身のKubernetesデプロイメント例では、サーバーがすべてのネットワークインターフェースでリッスンするように設定されており、事実上クラスターネットワークに対して公開されています。これらの構成では、ポートに到達できるホストであれば、誰でもこの脆弱性を悪用できます。

深刻さを増しているのは、LMCacheの公式コンテナイメージがプロセスをrootユーザーとして実行していることです。これは、攻撃が成功すると、攻撃者にホスト上の完全な管理者権限が付与されることを意味します。JFrogは、ファイアウォールで露出を制限することは可能ですが、許可範囲内の信頼できるホストが侵害された場合、リスクを完全に排除するわけではないと指摘しています。現在、サーバーがすでに攻撃されているかどうかを判断する方法は提供されていません。

仕組み

根本原因は、ZeroMQメッセージングライブラリを使用してプロセス間通信を処理するLMCacheの方法にあります。マルチプロセスサーバーは、ワーカープロセスが登録し、キャッシュデータを共有するためのソケットを開きますが、このソケットには認証メカニズムがありません。メッセージが届くと、サーバーはPythonのpickleモジュールを使用してデータを逆シリアル化します。Pickleは、デコード中に任意のコードを実行する可能性があるため、信頼できないデータに対して安全でないことが知られています。

重要なことに、サーバーはメッセージタイプを確認する前に、メッセージ引数を読み取っている間にpickleデータを展開します。この操作順序により、攻撃者は受信時に即座に実行される悪意のあるペイロードを送信できます。コードはLMCacheプロセスと同じ権限で実行され、前述のとおり、コンテナ化環境では通常root権限を持ちます。このパターンは、2025年11月に他のAI推論フレームワークで特定された「ShadowMQ」と呼ばれる一連の欠陥に似ていますが、直接的なコードリンクは確立されていません。

主要な詳細

• CVE識別子: CVE-2026-105192、深刻度評価は9.8/10。
• 影響を受けるバージョン: LMCache 0.3.9から0.5.5、さらに0.5.6リリース候補およびdevブランチ。
• 攻撃ベクトル: マルチプロセスモードでのZeroMQソケット経由の未認証ネットワークメッセージ。
• 根本原因: メッセージタイプ検証前のPython pickleを用いた安全でない逆シリアル化。
• 権限レベル: コードはLMProcessユーザーとして実行され、公式コンテナ内ではrootとなります。
• パッチ状況: 現時点で修正版は利用できません。

なぜ重要なのか

AIインフラを構築するエンジニアリングチームにとって、この脆弱性は、厳格なセキュリティ監査なしに新しい高速化ツールを採用することのリスクを浮き彫りにします。LMCacheはLLM推論を高速化するために設計されており、本番アプリケーションにとって重要なパフォーマンス指標です。しかし、プロジェクトが提供するデフォルトの例は、安全でないネットワークバインディングを推奨しています。これらの例に従ってマルチノードクラスタを設定する運用者は、気づかぬうちにシステムをリモートコード実行にさらしてしまいます。

パッチがないため、チームはパフォーマンスとセキュリティの間で選択を迫られます。ルーティング可能なアドレスを無効にすると、マルチノードキャッシュが破綻し、サービス品質が低下する可能性があります。開いたままにしておくと、攻撃者への扉が大きく開かれることになります。この状況は、アプリケーションレベルのセキュリティだけに頼るのではなく、厳格なネットワークセグメンテーションや最小権限原則など、多層防御戦略の重要性を強調しています。

さらに、GitHub上の6件の未確認のセキュリティレポートの発見は、プロジェクト内のより広範な衛生状態の問題を示唆しています。これらはCVEやメンテナーによる確認を欠いていますが、テナントデータや他のサービスへの未認証アクセスの可能性を示しています。LMCacheを使用するチームは、この特定のCVEだけでなく、プロジェクト全体のセキュリティ体制と新たな脅威への対応も監視する必要があります。

対処法

• ネットワークアクセスの制限: LMCacheマルチプロセスサーバーがlocalhostまたは信頼できる隔離されたクラスターネットワークでのみリッスンするように設定してください。
• 公開バインディングの回避: サーバーを信頼できないネットワークやインターネットからアクセス可能なルーティング可能なアドレスにバインドしないでください。
• ファイアウォールの実装: ファイアウォールルールを使用して、LMCacheポートに接続できるIPアドレスを厳密に制限してください。ただし、これだけでリスクを完全に軽減できるわけではないことに注意してください。
• コンテナ権限の確認: 可能な場合、コンテナ設定を変更してLMCacheプロセスを非rootユーザーとして実行し、攻撃の影響を制限してください。
• 更新の監視: この特定のCVEだけでなく、プロジェクト全体のセキュリティ体制と新たな脅威への対応も監視してください。