vLLMで新たに発見されたメモリ破損の脆弱性により、攻撃者が悪意のあるプロンプト埋め込みをCompletions APIに送信することで、サーバーをクラッシュさせたり任意のコードを実行したりできる可能性があります。
この脆弱性はvLLMバージョン0.10.2以降に影響し、本番環境のAI導入を即座に危険にさらします。
「この脆弱性により、APIへのアクセス権を持つ任意のユーザーが、vLLMサーバープロセスでサービス拒否（DoS）やリモートコード実行を達成できる可能性があります」とWiz Securityの研究者は述べています。
vLLMバグの根本原因の理解
この脆弱性（CVE-2025-62164）は、vLLMがユーザーから提供されたプロンプト埋め込みを処理する方法に起因しています。この機能は、高度なアプリケーションが事前計算済みのベクトルを直接モデルに渡せるように設計されています。
クライアントが埋め込みをCompletions APIに送信すると、vLLMはPyTorchのtorch.load()関数を使ってBase64エンコードされたペイロードをデシリアライズし、テンソルを再構築しようとします。
この問題はentrypoints/renderer.pyで発生します。ここでvLLMはBase64エンコードされた埋め込みをデコードし、torch.load()でデシリアライズします。
テンソルをロードした直後、サーバーはto_dense()でそれを密テンソルに変換しますが、整合性や安全性のチェックを一切行っていません。
このコード部分では、vLLMはユーザーが提供した埋め込みを単純に受け取り、torch.load(io.BytesIO(pybase64.b64decode(embed, validate=True)), weights_only=True, map_location=torch.device(“cpu”))でロードし、その後何の検証もせずにtensor = tensor.to_dense()を実行します。
この時点でvLLMはテンソルが有効かつ安全であると仮定しているため、悪意を持って作成されたペイロードもデシリアライズ処理を通過でき、密化の過程でメモリ破損を引き起こし、サービス拒否やリモートコード実行の可能性を生み出します。
PyTorchの変更が生んだ脆弱性
PyTorch 2.8.0では、スパーステンソルの整合性チェックがデフォルトで無効化され、to_dense()を呼び出す前に必要だったインデックス範囲やテンソル形状の一貫性、内部不変条件の検証が削除されました。
これらのチェックは現在、torch.sparse.check_sparse_tensor_invariantsを使って明示的に再有効化する必要がありますが、vLLMはこの保護を実装していません。
その結果、攻撃者は想定外のメモリ範囲を指す内部インデックスを持つ不正なスパーステンソルを作成できます。
PyTorchはテンソルを正常にロードしますが、その後vLLMがto_dense()を呼び出すと、フレームワークは不正なテンソルを密メモリに完全展開しようとして、範囲外書き込みが発生し、メモリ破損の可能性が生じます。
攻撃者がこのvLLM脆弱性でできること
悪意のあるペイロードの作り方によっては、範囲外書き込みがいくつかの重大な結果をもたらす可能性があります。
重要な実行メモリが破損した場合、サーバーがクラッシュしサービス拒否（DoS）状態になるかもしれません。
より高度なケースでは、攻撃者が制御フローに影響を与えるメモリ領域を上書きすることで任意のコード実行を達成できる可能性もあります。
また、vLLMはGPUやモデル重み、ログ、機密データなどの重要なコンポーネントと並行して動作することが多いため、AIスタック内での横方向の侵害にもつながります。
脆弱なデシリアライズ経路は外部公開されたCompletions APIを通じて露出しているため、攻撃者は特権や事前アクセスを必要とせず、サーバーに埋め込みペイロードを送信できれば十分です。
デシリアライズ脆弱性の内部
このエクスプロイトチェーンは、安全でないデシリアライズの一例です。信頼できない入力が直接メモリ内オブジェクトとして再構築されます。vLLMの場合、リスクが増幅される理由は次の通りです：
- テンソルのデシリアライズは複雑かつメモリ消費が激しい。
- 埋め込みペイロードが検証レイヤーを一切通過しない。
- 基盤となるライブラリ（PyTorch）が不正なデータを黙認する。
要するに、システムは攻撃者が制御するバイト列を受け取り、それをスパーステンソルとして再構築し、PyTorchに密メモリへ展開させます—テンソルが必要な不変条件を満たしているかどうかの確認は一切ありません。
vLLM脆弱性を緩和するための重要なステップ
vLLMのデシリアライズ脆弱性の重大性を踏まえ、セキュリティチームはサーバー侵害リスクを低減するために多層的な緩和戦略を採用する必要があります。
- パッチ済みのvLLMバージョンへアップデートし、PyTorchのスパーステンソル整合性チェックを適用して安全でないデシリアライズを防ぎましょう。
- CompletionsAPIへのアクセスを制限・認証し、公開を取り下げ、強力な認証とレート制限を徹底しましょう。
- すべてのプロンプト埋め込みをAPIゲートウェイ、WAF、またはミドルウェアで検証・フィルタリングし、不正または信頼できないテンソルがvLLMに到達する前にブロックしましょう。
- vLLMを堅牢な環境で分離し、専用コンテナやVM、最小権限、セグメンテーション、非特権サービスアカウントを活用しましょう。
- エクスプロイトの兆候に対する監視とログ記録を有効化し、クラッシュ、不正埋め込み、デシリアライズ失敗、異常な推論挙動などを検知しましょう。
- ランタイムおよびインフラのセキュリティ強化として、ASLR、DEP/NX、ネットワーク分離、アクセス制御、ファジングや依存関係監査などの定期的なセキュリティテストを実施しましょう。
多層防御、継続的な監視、セキュア・バイ・デザインの原則により、将来の脅威をより早期に検知し、効果的に封じ込めることが可能になります。
AIインフラは主要な攻撃対象になりつつある
この脆弱性はAIセキュリティにおける重要なテーマを浮き彫りにしています。攻撃対象はモデルだけでなく、それを支えるグルーコード、推論エンジン、シリアライズライブラリ、データパイプラインも含まれるのです。
組織がより多くのLLM活用機能を導入するにつれ、vLLMやPyTorch、モデル提供APIなどの基盤フレームワークの脆弱性がますます魅力的な攻撃対象となっています。
このインシデントはまた、今回のPyTorchによる整合性チェックの無効化のような微妙な上流変更が、AIエコシステム全体に波及するセキュリティギャップを生み出すことも示しています。
AIインフラがよりモジュラー化・相互接続されていく中で、組織がパッチを適用し、厳格な入力検証を徹底しなければ、些細なデシリアライズの欠陥が全面的な侵害に発展する可能性があります。
