JFrogのセキュリティ研究チームは2026年10月7日(米国時間)、LLM推論サーバーvLLMと組み合わせて使われるキャッシュ基盤LMCacheに、認証なしで任意のコードを実行される欠陥(CVE-2026-105192)があると公表しました。深刻度はCVSS(脆弱性の深刻度を0〜10で表す指標)で9.8です。公表時点で修正版はありません。自社GPUでオープンモデルを動かし、LMCacheをマルチプロセスモードで使っている場合、外部から接続できる設定になっていないかをすぐに確認する必要があります。
LMCacheとは何で、どこが危ないのか
LMCacheは、LLMが文章を処理する途中で作る中間データ(KVキャッシュ)を保存・共有し、同じ前置きを持つリクエストの計算を省く仕組みです。長いシステムプロンプトやRAG(検索した文書をプロンプトに足す手法)の文書を何度も使うサービスでは、応答の速さとGPU費用に直結するため、vLLMと組み合わせて広く使われています。
問題があるのは「マルチプロセスモード」です。公式ドキュメントによると、このモードはLMCacheを独立したサービスとして動かし、同じマシン上の複数のvLLMから1つのキャッシュを共有させるためのものです。JFrogによると、このサービスが使う通信路(ZeroMQ)には認証がなく、届いたメッセージの一部がPythonのpickle.loadsで復元されます。pickleは復元の過程で任意のコードを実行できる形式で、信頼できない入力に使ってはいけないことが知られています。結果として、ポートに届くメッセージを1つ送るだけで、LMCacheを動かしているユーザーの権限でコードが実行されます。JFrogは、公式のコンテナイメージではこのプロセスがroot権限で動いていると指摘しています。
影響を受ける版と条件
対象は0.3.9(2025年10月公開)以降で、JFrogによると10月7日時点の最新安定版0.5.5、0.5.6のリリース候補版(rc3まで)、開発ブランチのすべてに問題のコードが残っています。LMCacheのセキュリティアドバイザリ一覧にも、執筆時点で本件の掲載はありません。
ただし、すべての利用者が同じ危険にさらされるわけではありません。マルチプロセスモードの通信ポートは既定でループバックアドレス(そのマシン自身からしか届かない宛先)に結び付けられており、9.8という評価は--hostで外部から届くアドレスを指定した場合のものです。vLLMの中にLMCacheを組み込んで1プロセスで動かす使い方では、このポートは開きません。
注意したいのは、公式リポジトリのKubernetes用設定例(DaemonSet)が--host "0.0.0.0"(全インターフェースで待ち受け)とhostNetwork: trueを指定している点です。この例を下敷きに構築したクラスタでは、ノードに届く通信なら誰でもポートに接続できる状態になっている可能性があります。
なぜ同じ種類の欠陥が繰り返されるのか
推論基盤では、プロセス間で大きなデータを速く受け渡すためにZeroMQとpickleを組み合わせる実装がよく使われます。2025年11月には「ShadowMQ」という調査で、認証のない通信をpickleで復元する同じ型の欠陥が複数の推論フレームワークで見つかりました。The Hacker Newsの報道によると、LMCacheとそれらのコードの出どころが同じかどうかは確認されていません。性能を優先した内部通信が、構成次第でそのまま外部に開いてしまうという構造は共通しています。
関連して、vLLM側でもLMCacheのマルチプロセス用コネクタを有効にしていると、細工したcache_saltを含むリクエスト1つでエンジンが停止する欠陥(GHSA-2823-qmq8-rwvj、深刻度6.5)が報告され、0.30.0で修正されています。こちらはコード実行にはつながりませんが、同じ構成を使っている場合はあわせて更新が必要です。
日本の開発チームへの影響と対処
日本でも、データを社外に出せない業務向けに、自社GPUやクラウドのGPUインスタンスでオープンモデルをvLLMで動かす構成が増えています。応答を速くする目的でLMCacheを足しているチームは、手元の構成を確認する価値があります。JFrogは、すでに攻撃を受けたかどうかを見分ける方法は示していません。ファイアウォールで接続元を絞っても、接続できる端末が1台でも乗っ取られればコードを実行されるため、根本対策は修正版を待つしかありません。AI開発基盤の欠陥としては、9月にMCP公式Python SDKの認証情報流出の欠陥も報じられています。
今日やることは3つです。1つ目、lmcache serverやlmcache.v1.multiprocess.serverの起動引数を検索し、--hostに外部向けアドレスを指定していないか確かめる。2つ目、公式のDaemonSet例を使っている場合は、--hostをループバックアドレスに戻せないか検討し、難しければノードのファイアウォールで通信ポート(例では6555番)への接続元を必要なvLLMだけに絞る(hostNetwork: trueのPodにはKubernetesのネットワークポリシーが効かないことが多い点に注意)。3つ目、LMCacheのリリースとアドバイザリを監視し、修正版が出たら更新する。vLLMは0.30.0以降への更新も忘れずに行ってください。
