LLM推論高速化ツール「LMCache」に深刻な未修正の脆弱性、認証なしで遠隔コード実行の恐れ

要点

• 大規模言語モデル（LLM）の推論サーバーを高速化するオープンソース「LMCache」に、認証なしで遠隔からコードを実行できる深刻な脆弱性が判明した。

• 脆弱性（CVE-2026-105192）の深刻度スコアは10点満点中9.8と極めて高いが、現時点で修正パッチは提供されていない。

• マルチプロセス機能の通信部でPythonのpickle形式を無検証で展開する設計が原因で、公式コンテナではroot権限を奪われる恐れがある。

• 脆弱性を発見したセキュリティ企業のJFrogは、修正版が出るまでの暫定対策として、サーバーを外部公開アドレスに割り当てないよう注意を促している。

• セキュリティ企業のJFrogは2026年10月7日、大規模言語モデル（LLM）の推論サーバーを高速化するオープンソースソフトウェア「LMCache」において、認証を経ずに外部から任意のコードを実行できる重大な脆弱性が存在することを明らかにした。この脆弱性は「CVE-2026-105192」として管理されており、深刻度スコアは10点満点中9.8の「緊急（Critical）」と判定されている。現時点で修正パッチはリリースされておらず、最新版を含む広範なバージョンが危険にさらされている状態だという。

影響を受けるバージョンと脆弱性の深刻度

今回報告されたCVE-2026-105192は、LMCacheのバージョン0.3.9（2025年10月公開）から最新安定版の0.5.5までに加え、0.5.6のリリース候補版や開発ブランチにまで存在している。この欠陥は、JFrogのセキュリティ調査チームに所属するユヴァル・モラヴチク（Yuval Moravchick）氏によって発見された。

LMCacheは、vLLMなどのLLM推論処理エンジンと連携して動作するキャッシュソフトウェアだ。今回の脆弱性が悪用された場合、攻撃者は事前のログインや認証手続きを一切行うことなく、LMCacheプロセスを実行しているユーザー権限で任意のシステムコマンドを実行できてしまう。とりわけプロジェクトが公式に配布しているコンテナイメージでは、該当プロセスがroot（管理者権限）として動作しているため、マシン全体の制御権を奪われる危険性があるとJFrogは指摘している。

認証なきZeroMQ通信とpickle処理が引き起こすコード実行

問題の根本的な原因は、LMCacheが備える「マルチプロセスモード」の実装にある。このモードではキャッシュ機能が独立したスタンドアロンサーバーとして稼働し、LLMのワーカープロセス群がメッセージングライブラリの「ZeroMQ（軽量な非同期メッセージング機構）」を経由してキャッシュサーバーに接続する。

しかし、このマルチプロセスサーバーが待ち受けるZeroMQソケットには認証機構が設けられていなかった。さらに、受信したメッセージ引数を読み込む段階で、Pythonのデータ形式である「pickle（オブジェクトを保存・復元するための仕組み）」を用いてデータが展開される仕様となっていた。pickleはデータの復元時に内部に含まれる実行コードをそのまま動作させてしまう性質を持つ。LMCacheサーバーはメッセージの種別を検証する前にpickleを展開してしまうため、攻撃者が細工したネットワークパケットを1つ送り込むだけで、送信者側のコードが実行されてしまう構造になっていた。

露出条件とKubernetes向け公式設定例の落とし穴

この脆弱性が実際に外部からの攻撃にさらされるかどうかは、サーバーがバインドされているネットワーク設定に依存する。デフォルトの状態では、マルチプロセスサーバーはローカルマシン（localhost）からの接続のみを待ち受けるため、外部ネットワーク上の端末から直接パケットを送り込むことはできない。

しかし、複数のノードでキャッシュを共有するマルチノード構成などで外部マシンからアクセスさせるため、管理者がルーティング可能なネットワークアドレスを指定して起動した場合、外部からの侵入経路が開かれてしまう。注目すべき点として、LMCacheプロジェクトが公式に提供していたKubernetes向けのDaemonSet（クラスタ内の全ノードでポッドを実行する管理手法）設定例において、まさにこのマルチプロセスサーバーをすべてのネットワークインターフェースで待ち受けさせる記述がなされていたことが挙げられる。なお、単一のvLLMプロセス内部で完結して動作するスタンドアロン構成のLMCacheであれば、ポート自体が開かれないため影響は受けない。

パッチ未提供下での回避策と現状の対応

現時点でプロジェクト側から修正パッチは公開されておらず、公式なセキュリティアドバイザリ（脆弱性勧告）も発行されていない。また、JFrogのアドバイザリにも、サーバーがすでに攻撃を受けたかどうかを判定するための具体的な調査方法は記載されていない。

修正版が提供されるまでの暫定対応として、JFrogはマルチプロセスサーバーにルーティング可能なアドレスを割り当てない運用を呼びかけている。具体的には、サーバーの待ち受け先をローカルマシンのみに限定するか、信頼できるクラスタネットワーク内に留める必要があるという。ファイアウォールを用いてポートへの接続元を制限する方法も提示されているが、接続を許可された端末からは依然としてコード実行が可能となるため、リスクを根本的に排除できるわけではないと説明されている。

相次ぐセキュリティ懸念と関連ソフトウェアの動向

LMCacheを巡っては、CVE-2026-105192の公表前日である10月6日にも、GitHubのIssue上で単一のアカウントから6件に及ぶセキュリティ上の懸念が報告されていた。これらには、異なるテナント間でキャッシュデータに認証なしでアクセスできる問題や、ログインなしでコマンドを実行できる複数のネットワークサービスが存在するとの主張が含まれている。ただし、これらは概念実証（PoC）の提示にとどまり、CVEの採番やメンテナによる公式確認、修正対応はなされていない。なお、0.5.5で全インターフェースに公開されていた管理用HTTPサーバーが、0.5.6のリリース候補版でローカルホスト限定に変更されるなど、一部の設定見直しは見られる。

一方、連携対象であるvLLM側では、関連する別の脆弱性が既に対処されている。2026年9月22日にリリースされたvLLM 0.30.0以前には、LMCacheのマルチプロセスコネクタを利用している環境において、不正な「cache_salt」値を含むリクエストによって推論エンジンをクラッシュさせられるサービス拒否（DoS）の脆弱性（CVE-2026-105756、深刻度スコア6.5）が存在していたが、こちらはコード実行には至らず、修正済みとなっている。

認証のないネットワークソケットから渡されたデータをpickleで展開するという根本的な過ちは、2025年11月に研究者チームが複数のAI推論フレームワークで発見した脆弱性群「ShadowMQ」と同一のパターンである。LMCacheのコードがそれらのプロジェクトと共通のソースコードを共有しているかどうかについては、現時点では明らかになっていない。