新たに発見されたvLLMのメモリ破損脆弱性により、攻撃者は悪意のあるプロンプト埋め込みをCompletions APIに送信することで、サーバーをクラッシュさせたり、任意のコードを実行したりできる可能性がある。
この脆弱性はvLLMバージョン0.10.2以降に影響し、本番環境のAI導入を直ちに危険にさらす。
「この脆弱性により、APIにアクセスできるあらゆるユーザーが、vLLMサーバープロセスに対してサービス拒否やリモートコード実行を引き起こす可能性がある」とWiz Securityのセキュリティ研究者は述べた。
vLLMバグの根本原因を理解する
この脆弱性（CVE-2025-62164）は、vLLMがユーザー提供のプロンプト埋め込みを処理する方法に起因する。これは、高度なアプリケーションが事前計算済みのベクトルをモデルに直接渡せるようにするための機能だ。
クライアントがCompletions APIに埋め込みを送信すると、vLLMはBase64でエンコードされたペイロードを、PyTorchのtorch.load()関数でデシリアライズしてテンソルを再構築しようとする。
問題が発生するのは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インフラがよりモジュール化され相互接続されるにつれ、些細なデシリアライズの欠陥でさえ全面的な侵害に発展する可能性がある。