2026年2月2日、LLM推論エンジンvLLMにCVSSスコア9.8のリモートコード実行（RCE）脆弱性 CVE-2026-22778 が公開された。マルチモーダル動画処理パイプラインを経由し、未認証の攻撃者が推論サーバ上で任意コマンドを実行できるという深刻な欠陥である。vLLMはHugging Faceダウンロード数で月間数百万を記録し、本番環境のAI推論基盤として急速に普及している。本稿では、この脆弱性の技術的メカニズムを分析し、LLMサービング層に求められるセキュリティ設計パターンを体系化する。

CVE-2026-22778の技術的概要 ── 2段階の攻撃チェーン

CVE-2026-22778は単一のバグではなく、情報漏洩とヒープベースバッファオーバーフローを連鎖させた2段階の攻撃チェーンである。影響を受けるバージョンはvLLM 0.8.3から0.14.0までで、0.14.1で修正された。

第1段階：ASLR無効化のための情報漏洩（CWE-532）
攻撃者がマルチモーダルエンドポイントに不正な画像を送信すると、PIL（Python Imaging Library）が例外を発生させる。脆弱なバージョンのvLLMはこのエラーメッセージをクライアントにそのまま返却しており、メッセージにはByteIOオブジェクトのヒープメモリアドレス（例：object at 0x7a95e299e750）が含まれていた。このアドレスはlibcの約10.33GB手前に位置しており、ASLR（Address Space Layout Randomization）の有効な組み合わせ数を約40億通りからわずか約8通りにまで縮小させる。

第2段階：JPEG2000デコーダのヒープオーバーフロー（CWE-122）
vLLMはOpenCVを使用して動画コンテンツを処理する。そのOpenCVにバンドルされたFFmpeg依存のJPEG2000デコーダには、チャネル定義（cdef）ボックスを利用したカラーチャネルのリマッピング機能がある。攻撃者は細工した動画ファイルにおいて、Y（輝度）チャネルのデータをU（色差）バッファに書き込むようcdefボックスを操作する。Yプレーンのサイズ（W×H）はUバッファのサイズ（(W/2)×(H/2)）の4倍であるため、典型的な150×64ピクセルのフレームで約7,200バイトのヒープオーバーフローが発生する。このオーバーフローはAVBufferのfreeポインタなどの関数ポインタを上書きし、バッファ解放ルーチンを通じて任意のシステムコマンドを実行させる。

攻撃面の分析 ── なぜLLMサービング層が狙われるのか

この脆弱性の攻撃ベクトルは、POST /v1/chat/completionsまたはPOST /v1/invocationsエンドポイントに対して悪意ある動画URLを送信するだけで成立する。認証は不要であり、ネットワーク経由でリモートから実行可能である（CVSSベクトル：AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）。

LLMサービング層が新たな攻撃面として拡大している背景には、3つの構造的要因がある。第一に、マルチモーダル処理の複雑性である。テキストのみのLLMとは異なり、画像・動画・音声を受け付けるマルチモーダルモデルは、FFmpeg、OpenCV、PILなど多数のメディア処理ライブラリに依存する。これらのライブラリはC/C++で実装されており、メモリ安全性の問題を内在している。第二に、推論サーバの特権的位置である。vLLMサーバはGPUメモリに直接アクセスし、モデルの重みやコンテキストウィンドウ内の機密データを保持している。サーバが侵害されれば、推論データの窃取やモデル汚染が可能になる。第三に、認証の欠如が常態化している点である。多くのvLLMデプロイメントではOpenAI互換APIがデフォルト設定のまま公開されており、API認証が適切に設定されていない。

EPSS（Exploit Prediction Scoring System）スコアは2026年2月時点で0.068%（21パーセンタイル）と報告されているが、詳細な技術的解析が公開されていることから、実際の攻撃試行が短期間で出現する可能性は高い。

影響範囲の特定 ── 動画モデルを提供していない場合の安全性

重要な点として、CVE-2026-22778は動画モデルを提供するvLLMデプロイメントのみが影響を受ける。テキスト専用モデルや静止画のみを処理するマルチモーダルモデルでは、動画処理コードパスに到達しないため、この特定の脆弱性は悪用できない。

ただし、この脆弱性は氷山の一角と捉えるべきである。2025年12月にはvLLMの別の脆弱性CVE-2025-66448（CVSS 7.1）が公開されており、こちらはtrust_remote_code=Falseを設定していても、悪意あるモデルリポジトリのconfig.jsonにあるauto_mapエントリを通じてリモートコードが実行される問題であった。推論エンジンの攻撃面は、メディア処理だけでなく、モデルロード、設定解析、プラグインシステムなど多岐にわたる。

LLMサービング層の防衛設計パターン

CVE-2026-22778の教訓を踏まえ、LLMサービング層に適用すべき防衛設計パターンを体系化する。

1. 入力検証とメディアURL制限
vLLM 0.14.1以降では--allowed-media-domainsオプションが導入され、メディアURLのドメインを制限できるようになった。マルチモーダルエンドポイントでは、受け入れるファイル形式・サイズ・ドメインを明示的にホワイトリスト制御すべきである。SSRF（Server-Side Request Forgery）対策として、推論サーバから内部ネットワークへのリクエストも遮断する必要がある。

2. メディア処理のサンドボックス化
C/C++で実装されたメディアデコーダは本質的にメモリ安全性のリスクを持つ。動画・画像のデコード処理をgVisorやFirecracker microVMなどのサンドボックス環境で実行することで、バッファオーバーフローが発生しても推論サーバ本体への影響を遮断できる。seccompプロファイルを適用し、デコード処理に不要なシステムコールを制限することも有効である。

3. ネットワーク分離とゼロトラスト設計
vLLMの公式セキュリティガイドでも、ノード間通信はデフォルトで暗号化されておらず、隔離されたネットワーク上に配置する必要があると明記されている。推論APIを公開する場合は、APIゲートウェイまたはリバースプロキシを前段に配置し、認証・レート制限・WAF（Web Application Firewall）を適用する。内部通信ポートは公開インターネットに露出させてはならない。VLLM_HOST_IPを明示的に設定し、デフォルトの全インターフェースリッスンを回避することも重要である。

4. エラーメッセージの制御
CVE-2026-22778の第1段階はエラーメッセージ内のメモリアドレス漏洩に起因する。本番環境では詳細なスタックトレースやデバッグ情報をクライアントに返却してはならない。VLLM_SERVER_DEV_MODE=1を本番環境で設定しないことは当然として、APIゲートウェイ層でエラーレスポンスをサニタイズし、内部情報が外部に漏洩しない設計を徹底する必要がある。

5. 依存ライブラリのサプライチェーン管理
今回の脆弱性はOpenCVにバンドルされたFFmpegのJPEG2000デコーダに起因しており、vLLM本体のコードではない。推論エンジンの依存ツリーを可視化し、SBOMを管理することで、間接依存に含まれるC/C++ライブラリの脆弱性を追跡する体制が求められる。定期的な依存関係スキャンとパッチ適用プロセスの自動化が不可欠である。

今後の展望 ── AI推論インフラのセキュリティ成熟度

vLLMの脆弱性は、AI推論基盤が従来のWebアプリケーションやデータベースサーバと同等のセキュリティ要件を持つことを改めて示した。マルチモーダルAIの普及に伴い、推論サーバが処理するデータの種類と複雑性は今後も増大する。WebカメラやIoTデバイスからのリアルタイム動画ストリーム処理、3Dモデルやポイントクラウドの入力など、攻撃面はさらに拡大するだろう。

AI推論インフラのセキュリティ成熟度を向上させるためには、推論エンジン開発者、クラウドプロバイダ、そして利用企業の三者が協調する必要がある。推論エンジン開発者はメモリ安全な言語（Rustなど）でのメディアパーサー再実装を検討すべきであり、クラウドプロバイダは推論ワークロード向けの隔離実行環境を標準提供すべきである。利用企業は推論サーバを「信頼された内部コンポーネント」ではなく「外部からの入力を処理する境界サービス」として設計思想を転換する必要がある。

FAQ

CVE-2026-22778はどのバージョンのvLLMに影響するのか？

vLLM 0.8.3から0.14.0までが影響を受ける。0.14.1で情報漏洩とヒープオーバーフローの両方が修正されており、即座にアップグレードすべきである。

動画モデルを使用していない場合もリスクがあるのか？

CVE-2026-22778は動画処理コードパスを経由するため、動画モデルを提供していないデプロイメントは影響を受けない。ただし、別の脆弱性（CVE-2025-66448等）は動画に依存しないため、総合的なセキュリティ対策は必要である。

vLLM推論サーバのセキュリティで最低限行うべき対策は何か？

ネットワーク分離（内部ポートの非公開化）、APIゲートウェイでの認証適用、--allowed-media-domainsによるURL制限、本番環境でのデバッグモード無効化の4点を最優先で実施すべきである。

ASLR回避はどのように行われるのか？

不正画像の送信時にPILが返すエラーメッセージにByteIOオブジェクトのヒープアドレスが含まれており、libcのベースアドレスを約8通りに絞り込める。これにより後段のヒープオーバーフロー攻撃の成功率が大幅に向上する。

参考文献