vLLM脆弱性【2026年10月24日時点】CVE-2026-114055

最終更新：2026年10月24日（JST）

vLLMは、LLMをAPIとして高速に提供するために使われる推論・サービング基盤です。今回のCVE-2026-114055は、画像や動画などを扱うマルチモーダル処理に渡すリクエスト単位の設定が十分に検証されず、過大なメモリ確保を引き起こせる問題です。vLLMリポジトリのSecurity Advisoryは、1件の要求でもAPIサーバーまたはワーカーがOOM（Out of Memory）で終了し、共有する利用者全体がサービスを使えなくなる可能性を説明しています。

ここで重要なのは、影響を広げすぎないことです。この告知は、外部から任意のプログラムを実行される脆弱性でも、情報漏えいやデータ改ざんを示す告知でもありません。公式の評価範囲は可用性への影響です。一方で、社内のAIエージェント、チャット画面、RAG、Claude CodeやCodex系クライアントが同じvLLMを共有していれば、その推論基盤が止まることで複数業務が同時に失敗する可能性があります。

vLLMは10月6日にリポジトリの勧告を公開し、GitHub Advisory Databaseには10月23日付で登録されました。配信記録の2026年10月24日05時58分（JST）はデータベースへの反映時刻であり、脆弱性が最初に公開された時刻ではありません。以下では、正規のGHSA、CVEレコード、修正PR、リリースノート、公式ドキュメントを基に、版の判定から復旧確認までを順に整理します。

対象版と修正版を先に確認する

GitHub Advisory DatabaseのReviewed AdvisoryとCVE-2026-114055の公式レコードが示す範囲は、次のとおりです。

vLLM v0.31.0のリリースノートにも、リクエストごとのmm_processor_kwargsとmedia_io_kwargsを既定で拒否する変更が記載されています。2026年10月24日時点では、PyPIにvLLM 0.32.0も公開されています。最初の修正版は0.31.0ですが、運用環境では依存関係とモデルの互換性を確認し、0.31.0以上の検証済み版へ上げてください。

コンテナのタグや構成ファイルだけでなく、実際に稼働している全レプリカの版を確認します。ローリング更新の途中で古いPodが残る、検証系だけ古いイメージを使う、再起動後に曖昧なタグから古いキャッシュを参照する、といった差があるためです。vLLMのオンラインサービングには版と正常性を確認するエンドポイントがあるので、管理ネットワークから実行中サービスを確認してください。

Linuxディストリビューションのパッケージを使う場合は、表示された上流版だけを単純比較せず、提供元のセキュリティ告知に掲載された修正済みパッケージ版と照合します。ディストリビューションは古く見える上流版へ修正をバックポートし、末尾の改訂番号で区別することがあるためです。今回のGHSA、CVE、NVDには、特定ディストリビューションの修正済みパッケージ番号は掲載されていません。

CVE-2026-114055で何が起きるのか

リクエスト側の設定が画像・動画処理まで渡っていた

問題の中心は、クライアントがリクエストごとに指定できたmm_processor_kwargsです。影響版では、その値がオンラインのレンダリング処理を経て、Hugging Faceまたは独自の画像・動画プロセッサーの生成や処理へ渡されます。画像サイズ、パッチ、クロップ数、フレーム数など、CPU、GPU、メモリの使用量に関係する値まで外部入力で変えられる経路がありました。

公式勧告はIsaac系プロセッサーの経路を具体例に挙げ、アップスケールを伴う画像処理で非常に大きなメモリ確保が生じ得ると説明しています。InternVL派生、H2OVL、Step3VL、NemotronVLなどにも同種の転送経路があるとしていますが、これは網羅的な対象モデル一覧ではありません。「記載されたモデルを使っていないから対象外」と判断せず、vLLMの版、オンラインAPIの公開範囲、マルチモーダル入力の有無で確認する必要があります。

確認された影響はサービス停止

公式に確認できる結果は、CPUまたはGPUメモリの枯渇と、APIサーバーまたはワーカーのOOM終了です。共有基盤なら、そのプロセスを使うほかの利用者も推論サービスを利用できなくなります。API認証が任意の構成で外部から到達できる場合は、権限を持たない相手から要求が届く可能性もあります。インターネットへ直接公開していなくても、複数部署、委託先、顧客、社内エージェントが共有し、すべてのクライアントを信頼できない場合は確認対象です。

深刻度はHigh、評価方式により7.5と8.7がある

GitHubのReviewed Advisoryは、深刻度をHigh、CVSS v3.1を7.5としています。ベクターは、ネットワーク経由、攻撃の複雑度が低い、権限不要、利用者操作不要、機密性と完全性への影響なし、可用性への影響が高いという評価です。CVEレコードにはCVSS v4.0の8.7／Highも掲載されています。評価方式が異なる数字なので、混ぜて「8.7へ引き上げられた」とは解釈しません。

修正版が変えた入力境界と一時対策の有無

修正PR #58830は、非空のリクエスト単位mm_processor_kwargsとmedia_io_kwargsをAPIサーバー側で既定拒否するよう変更しました。ChatやCompletionだけでなく、Pooling、Scoring、Responses APIのレンダリング経路も検証対象です。管理者がサーバー起動時に固定する設定や、オフラインLLMでの指定は残されています。

互換性が必要な信頼済み環境向けに、--trust-request-mm-kwargsという明示的な起動フラグがあります。ただし、vLLMのSecurity Guideは、信頼できないクライアントに公開するエンドポイントではこのフラグを有効にしないよう説明しています。0.31.0以上であっても、起動引数を見ずに「版だけで安全」と判断しないことが大切です。

結論として、公式告知にCVE固有の一時対策はありません。リバースプロキシでの認証、許可するエンドポイントの制限、レート制限、ログ取得、リクエストごとのリソース監視は重要ですが、公式はこれらを完全な回避策とはしていません。業務都合で更新に時間がかかる場合も、一般的な防御を更新の代わりにせず、外部・非信頼クライアントから対象APIへ到達できる範囲を縮小し、更新を優先してください。

今日やること：確認、更新、再起動、前後の確認

作業は、止める前の証跡を残し、実行中の版を確定してから進めます。以下は防御と復旧の手順であり、脆弱性を再現する要求は送りません。

1．稼働中の版と公開経路を確認する

• Pythonパッケージ、コンテナタグまたはイメージdigest、デプロイ定義を確認します。
• 管理ネットワークから実行中サービスの/versionを確認し、全APIサーバー、ワーカー、Pod、レプリカを一覧化します。
• OpenAI互換API、Responses API、Anthropic Messages API、マルチモーダル入力がどの入口から同じvLLMへ届くか確認します。
• 起動引数に--trust-request-mm-kwargsがないか確認します。付いている場合は、利用者を本当に信頼できる閉じた構成かを見直します。

0.7.3以上0.31.0未満なら更新対象です。ロードバランサー配下に版が混在している場合は、一部だけの更新で完了にしません。画像を扱っていないと思っていても、APIゲートウェイやクライアントが追加フィールドをそのまま通す構成なら、入力経路を確認してください。

2．更新前のログと監視値を保全する

• vLLMのアプリケーションログ、リバースプロキシとAPIゲートウェイのアクセスログを保存します。
• コンテナやKubernetesの終了理由、再起動履歴、ノードイベントを保存します。
• OSのOOM記録、CPU・GPU・メモリ使用量、5xx、ヘルスチェック失敗の時間帯を残します。
• APIキーや認証ログは必要な担当者だけが扱い、プロンプト、画像、個人情報を調査外へ不用意に複製しません。

再起動すると、揮発ログやコンテナの状態が失われることがあります。更新を急ぐ場合でも、取得できる範囲の証跡を先に確保してください。

3．0.31.0以上へ更新する

互換性を確認した0.31.0以上の版へ更新します。最初の修正版は0.31.0です。コンテナでは、内容が後から変わり得る曖昧なタグだけに頼らず、検証したタグまたはdigestをデプロイ定義へ固定します。Python環境では依存関係を含む固定情報を保存し、検証環境で起動と通常推論を確認します。

0.7.3未満へ戻す方法は取りません。その版はこのCVEの対象範囲外ですが、古いソフトウェアには別の修正不足や互換性問題があり得ます。公式の修正版を使うのが基本です。

4．全プロセスを再起動または再デプロイする

パッケージやイメージを置き換えただけでは、メモリ上の古いプロセスは変わりません。APIサーバー、ワーカー、Pod、全レプリカを修正版で再起動または再作成します。更新時間中は、同じvLLMへ接続する自動エージェントを止めるか別系統へ切り替え、処理の二重実行を避けます。

5．更新後の版、正常性、業務動作を確認する

• 全レプリカの/versionが0.31.0以上であることを確認します。
• /health、通常のテキスト推論、業務で使うマルチモーダル処理を確認します。
• 信頼できないクライアント向けのプロセスで--trust-request-mm-kwargsが無効であることを確認します。
• 更新前後のエラー、5xx、OOM、CPU・GPUメモリ、Pod再起動数を比較します。
• 失敗したエージェントのジョブを再実行する前に、メール送信、チケット作成、データ更新などが既に完了していないか確認します。

この順序は、同じ製品群の脆弱性対応にも応用できます。運用担当者は、PHPの緊急脆弱性で確認すべき更新と初動や、Node.jsのセキュリティリリースでの版確認もあわせて確認してください。

入られていないかを確かめる

公式告知に書かれていること

vLLMの告知には、侵害指標（IOC）、攻撃元、ログ上の固有パターン、検知コマンド、実被害企業の記載がありません。実悪用の有無についても、vLLMの告知本文には記載がありません。CVEレコードへ付加されたCISAのSSVC評価は10月21日時点で「Exploitation: none」、10月23日版のCISA Known Exploited Vulnerabilities Catalogには本CVEが収録されていませんが、これは悪用が絶対になかったことや今後もないことの証明ではありません。

また、公式の影響は可用性です。このCVEだけを根拠に、サーバーへ侵入された、任意コードを実行された、情報を盗まれた、データを書き換えられたとは判断できません。まず確かめるのは、対象となる入力と、リソース急増、OOM、サービス停止の時間的なつながりです。

一般的な運用確認として見るもの

1. 保存済みのプロキシ、APIゲートウェイ、アプリケーションログで、mm_processor_kwargsまたはmedia_io_kwargsを含む要求が記録されていないか確認します。
2. 同じ時間帯のCPU・GPUメモリ急増、OOM終了、5xx、ヘルスチェック失敗、Podやワーカーの再起動を突き合わせます。
3. 当時使っていたAPIキー、接続元、社内エージェント、チャット画面、外部公開経路を確認します。
4. 作成した覚えのないアカウント、不審な設定変更・プロセス・セッション・外部通信がないか、別の侵害兆候として確認します。

リクエスト本文を記録していなかった環境では、該当フィールドを後から確認できない場合があります。ログに見当たらないことを、そのまま「悪用なし」の証明にはできません。反対に、不審なアカウントや外部通信など、公式の可用性影響を超える異常が見つかった場合は、このCVEだけを原因と決めつけず、証跡を保全して社内CSIRTやセキュリティ事業者へつないでください。

IPAの不正アクセス事案を踏まえた注意喚起も、外部公開サービスの洗い出し、ログ量やログイン失敗・接続元・時刻の平時比較、覚えのないアカウントの確認、異常時の専門事業者による詳細調査を案内しています。これはCVE-2026-114055固有の検知手順ではなく、一般的な初動の参考です。

バックアップから戻せるか

このCVEではバックアップ復元が主な対処ではない

vLLMの告知には、バックアップ復元の案内はありません。公式に示された結果はメモリ枯渇によるプロセス停止であり、ファイル暗号化、データ消去、データ破損は影響に含まれていません。そのため、CVE-2026-114055だけを前提にした主な復旧策は、修正版への更新、全プロセスの再起動、正常性確認です。

ただし、更新前の構成を残す意味はあります。デプロイ定義、起動引数、モデル名と取得元、依存関係の固定情報、イメージdigest、エージェントの接続先設定を保存してください。復旧時に設定やモデルキャッシュを戻す場合も、実行バイナリやコンテナは必ず修正版を使い、脆弱版そのものへ戻さないでください。

復元できるかは平時に試す

別の侵害やデータ破損が同時に見つかった場合は、通常のインシデント復旧へ切り替えます。警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」のランサムウェア被害組織に関する集計では、バックアップを取得していたとの回答が44件あった一方、復元結果に回答した40件のうち29件は復元できませんでした。これはvLLMや本CVEの被害統計ではありません。

この公的統計から得られる教訓は、「バックアップがある」と「業務を復元できる」は別だということです。vLLMでは、設定、コンテナ、依存関係、モデルの取得元、ゲートウェイ設定、エージェント側の接続設定まで含めて、隔離した環境で復旧確認を行います。復旧後は版、起動引数、認証、APIの正常性、監視、接続する業務を再確認します。

Claude Code・Codex・MCP・社内エージェントとの関係

CVE-2026-114055は、Claude Code、Codex、MCPプロトコル、MCPサーバー自体の脆弱性ではありません。影響判断の中心は、それらのツールがモデルの接続先として影響版vLLMを使っているか、同じvLLM基盤をマルチモーダルAPIと共有しているかです。

vLLMのClaude Code連携ドキュメントは、vLLMがAnthropic Messages APIを実装し、接続先をvLLMへ向けられることを説明しています。通常どおりAnthropicのサービスへ接続しているだけなら、このvLLM脆弱性との直接関係はありません。Claude Codeが通常の処理でmm_processor_kwargsを送るとの記載もないため、Claude Codeを直接の攻撃経路とは断定できません。

vLLMはResponses APIから外部ツールサーバーへ接続する機能も持ちますが、公式Security Guideではツールサーバーは既定で有効ではなく、明示的な設定が必要です。MCPサーバーが存在するだけで本CVEの影響を受けるわけではありません。MCPツールを実行される、エージェントのAPIキーが盗まれる、入力データが漏れる、といった影響は公式告知から確認できません。

社内では、チャットUI、RAG、バッチ処理、画像解析、Claude Code、Codex、MCP連携をサービス名で分けるだけでなく、最終的にどのvLLMプロセスへ到達するかを一覧化します。同じ共有基盤を使うなら、更新時間中の停止告知、失敗ジョブの扱い、外部書き込みの重複防止まで決めておくと復旧を早められます。MCP自体のセキュリティ確認は、MCP TypeScript SDKの脆弱性解説も参照してください。

悪用状況と情報の読み方

2026年10月24日時点で、vLLMの公式勧告とGitHub Advisory Databaseには、この脆弱性が実際の攻撃で悪用されたとの記載はありません。CVEレコードのCISA補足は10月21日時点で「Exploitation: none」とし、確認時点のCISA KEVにも収録されていません。IPA、JPCERT/CC、JVN、国家サイバー統括室、警察庁の公式サイトをCVE番号とGHSA番号で確認した範囲でも、この脆弱性固有の注意喚起は確認できませんでした。

ただし、「記載がない」「KEVにない」は、悪用が一度もなかったことの証明ではありません。版の確認や更新を先送りする理由にもなりません。公式情報が更新された場合は、vLLMリポジトリの正規GHSA、CVEレコード、CISA KEVの順に確認し、二次情報だけで被害の有無を判断しないでください。

よくある質問

vLLM 0.30系はCVE-2026-114055の対象ですか？

はい。0.7.3以上0.31.0未満が影響範囲なので、0.30系は対象です。互換性を確認して0.31.0以上へ更新してください。

vLLM 0.31.0へ上げれば確認は終わりですか？

いいえ。全レプリカが修正版で再起動したか、実行中の/version、/health、起動引数、業務の通常推論を確認します。信頼できない利用者向けのサービスで--trust-request-mm-kwargsを有効にしないことも重要です。

テキストだけのモデルなら何もしなくてよいですか？

版の確認は必要です。公式告知の原因はマルチモーダル処理ですが、APIゲートウェイや共有基盤で画像・動画を扱う別経路がないかも含めて確認します。影響版なら、利用経路を自己判断で限定せず修正版へ更新してください。

認証やレート制限だけで完全に防げますか？

公式は認証、入力検証、レート制限、ログ取得を一般的な防御として推奨していますが、このCVE専用の完全な回避策とはしていません。告知に一時対策はなく、0.31.0以上への更新が必要です。

情報漏えいや任意コード実行も起きますか？

公式告知からは確認できません。CVSSは機密性と完全性への影響をなし、可用性への影響を高いと評価しています。別の侵害兆候があれば、本CVEとは切り分けて調査します。

Claude Codeをインストールしている会社は対象ですか？

Claude Codeの有無だけでは決まりません。ANTHROPIC_BASE_URLなどで推論先を自社vLLMへ変えており、そのvLLMが対象版なら更新対象です。通常のAnthropicサービスへ接続しているだけなら、このCVEの直接の対象ではありません。

悪用された証拠がなければ更新を待てますか？

待つ根拠にはなりません。公式告知に実悪用の記載がないことと、脆弱性の影響を受けないことは別です。対象版なら証跡を保全したうえで修正版へ更新してください。

結論と次の一歩

CVE-2026-114055の対象はvLLM 0.7.3以上0.31.0未満で、最初の修正版は0.31.0です。公式に確認できる影響は、検証されていないマルチモーダル処理の設定によるリソース過剰消費と、OOMを通じたサービス停止です。コード実行、情報漏えい、データ改ざんを示す告知ではありません。

今日の優先順位は、稼働版と接続経路の確認、更新前ログの保全、0.31.0以上への更新、全プロセスの再起動、更新後の版・正常性・業務確認です。経営者は「vLLMを使っているか」だけでなく、何件の業務やエージェントが同じ推論基盤を共有しているかを担当者へ確認してください。停止時の業務影響が分かれば、更新時間と代替経路を判断しやすくなります。

• 今日：実行中の版、全レプリカ、公開経路、起動引数を確認し、0.31.0以上への更新を始める。
• 運用確認：再起動前後のOOM、5xx、リソース使用量、ヘルスチェック、エージェントの失敗ジョブを照合する。
• 継続対応：認証、許可するAPI、レート制限、ログ、バックアップ復元試験を見直す。

AIを使った攻撃と企業の防御を広く整理したい場合は、AIサイバー攻撃の動向と中小企業の防御ガイドも参考にしてください。

参考・出典

• vLLM: DoS via unvalidated mm_processor_kwargs in multimodal image processors — vLLM／GitHub Security Advisory（参照日：2026年10月24日）
• GHSA-gx7p-2j49-hfq4 — GitHub Advisory Database（参照日：2026年10月24日）
• CVE-2026-114055公式レコード — CVE.org（参照日：2026年10月24日）
• CVE-2026-114055 — NVD（参照日：2026年10月24日）
• [Security] Gate per-request multimodal processor kwargs — vLLM修正PR #58830（参照日：2026年10月24日）
• vLLM v0.31.0リリース — vLLM（参照日：2026年10月24日）
• vLLM 0.32.0 — Python Package Index（参照日：2026年10月24日）
• Security — vLLM公式ドキュメント（参照日：2026年10月24日）
• Using vLLM with Claude Code — vLLM公式ドキュメント（参照日：2026年10月24日）
• Known Exploited Vulnerabilities Catalog — CISA（参照日：2026年10月24日）
• 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について — IPA（参照日：2026年10月24日）
• 令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について — 警察庁（参照日：2026年10月24日）

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・書籍シリーズ累計66,000部）、『AI推進担当になったら読む本』（大和書房）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談はお問い合わせフォームからお送りいただけます。