CVE-2025-62164 PoC：エンベッディングを攻撃対象に変えるvLLMの完了データプレーン・バグ

エグゼクティブ・サマリー

大規模言語モデル（LLM）インフラが成熟するにつれて、攻撃対象は従来の管理インターフェース（「制御プレーン」）から実際の推論データの流れ（「データプレーン」）へと移行しつつある。

CVE-2025-62164 におけるパラダイムシフト的な脆弱性を表している。 ブイエルエルエムこれは、高スループットの LLM サービングを実現する業界標準のエンジンである。この欠陥により、攻撃者は /v1/コンプリート エンドポイントに悪意のある プロンプト埋め込みPyTorchのロードロジック内の安全でないデシリアライズの仕組みを悪用することで、攻撃者はメモリ破壊を引き起こし、サービス運用妨害(DoS)や潜在的なリモートコード実行(RCE)を引き起こすことができます。

この分析では、技術的な根本原因を分解し、概念的な概念実証（PoC）を提供し、AIプラットフォーム・エンジニアのための早急な改善ステップの概要を示します。

攻撃ベクトル：エンベッディングが危険な理由

標準的なLLMインタラクションでは、ユーザーはテキストを送信する。しかし、vLLMのような高度な推論エンジンは 埋め込み入力 (テンソル・データ）をAPI経由で直接利用できる。これはパフォーマンスの最適化とマルチモーダルワークフローのために設計されているが、危険な扉を開いている： 直接オブジェクトのデシリアライズ.

脆弱性は、vLLMがこれらの入力テンソルを処理する方法に存在する。具体的には、エンジンはユーザーから提供された直列化されたデータの構造を暗黙的に信頼し、それが無害な数学的表現であると仮定します。

脆弱なコードパス

致命的な欠陥は vllm/entrypoints/renderer.py 内 _load_and_validate_embed（ロード・アンド・バリデート・エンベッド 関数である。

パイソン

# 脆弱なロジックの単純化された表現
インポートトーチ
インポート io
インポート pybase64

def _load_and_validate_embed(embed: bytes)：
    # DANGER: 信頼できないバイナリストリームのデシリアライズ
    tensor = torch.load(
        io.BytesIO(pybase64.b64decode(embed, validate=True))、
        weights_only=True, # 偽の安心感
        map_location=torch.device("cpu")、
    )
    テンソルを返す

一方 weights_only=True は、任意のPythonコードの実行（一般的なPickleの脆弱性）を防ぐためのものである。 足りない 特定の PyTorch のテンソル型を扱うときにメモリ破壊を防ぐためです。

テクニカル・ディープ・ダイブスパーステンソルの活用

CVE-2025-62164の核心は、PyTorchの安全フラグと、その処理である スパース・テンソル.

1. PyTorch 2.8+ シフト： PyTorchの新しいバージョンでは、パフォーマンスを向上させるために、スパーステンソルの高価な整合性チェックをスキップするようになっています。
2. バイパス 攻撃者は不正な「スパースCOO」（座標フォーマット）テンソルを構築することができる。たとえ weights_only=True, トーチロード はこの構造体をデシリアライズする。
3. メモリ破損： スパーステンソルのインデックスは、ロード中に宣言されたサイズに対して検証されないため、その後の操作（テンソルを密なフォーマットに変換したり、GPUメモリに移動したりするような）では アウトオブバウンズ（OOB）ライト.

このOOB書き込みはPythonインタプリタを即座にクラッシュさせる(DoS)。洗練されたヒープスプレーとメモリレイアウト操作により、このプリミティブは命令ポインタの制御を得るためにエスカレートすることができ、RCEを達成します。

概念実証（PoC）分析

免責事項：このPoCは教育的、防衛的な目的のみのものである。

1.ペイロードの構築

攻撃者は内部一貫性制約に違反するシリアライズされた PyTorch テンソルを作成します。

パイソン

インポートトーチ
インポート io
インポート base64

def generate_exploit_payload()：
    buffer = io.BytesIO()
    
    # アクセス時にOOB書き込みをトリガするように設計されたスパーステンソルを作成する。
    # 特定のインデックスが割り当てられたメモリの外側を指すように細工される
    # malformed_tensor = torch.sparse_coo_tensor(indices=..., values=..., size=...)
    
    # デモンストレーションのために、シリアライズをシミュレートします。
    # 実際の攻撃では、このバッファにバイナリpickleストリームが格納されます。
    torch.save(malformed_tensor, buffer)
    
    # JSONトランスポート用にエンコードする
    return base64.b64encode(buffer.getvalue()).decode('utf-8')

2.エクスプロイト・リクエスト

攻撃者はこのペイロードを標準の完了エンドポイントに送信する。

ポスト http://target-vllm-instance:8000/v1/completions

JSON

{
  "model"："meta-llama/Llama-2-7b-hf",
  "プロンプト"：{
    "embedding"：""
  },
  "max_tokens"：10
}

3.結果

• 最高のケースだ： vLLMワーカープロセスはセグメンテーションフォールトに遭遇し、クラッシュする。オーケストレーター（Kubernetesなど）がそれを再起動すると、攻撃者は単にリクエストを再送することができ、持続的なサービス拒否が発生する。
• 最悪のケース： メモリ破壊によって関数ポインタが上書きされ、攻撃者はコンテナ・コンテキスト内でシェルコードを実行できるようになる。

影響評価

• 可用性（高）： これは簡単に実行できるDoSである。単一のリクエストで推論ノードをダウンさせることができる。クラスタ化された環境では、攻撃者はクラスタ全体を劣化させるためにノードを繰り返し攻撃することができる。
• 機密性と完全性（重要）： RCEが達成されると、攻撃者は環境変数（多くの場合、Hugging Faceトークン、S3キー、WandBキーを含む）へのアクセスを獲得し、メモリにロードされた独自モデルのウェイトを獲得する。

修復と緩和

1.すぐにアップグレードする

この脆弱性は vLLM v0.11.1.

• アクション DockerイメージやPyPIパッケージをすぐに最新バージョンに更新しましょう。
• ロジックを修正する： このパッチは、安全でないテンソル・フォーマットをメモリ・アロケータとやりとりする前に拒否する厳格な検証ロジックを実装している。

2.入力サニタイゼーション（WAF/ゲートウェイレベル）

すぐにアップグレードできない場合は、ゲートウェイで攻撃ベクトルをブロックしなければならない。

• アクション APIゲートウェイ（Nginx、Kong、Traefik）を設定して、受信するJSONボディを検査する。
• ルール へのいかなるリクエストもブロックする。 /v1/コンプリート ここで 迅速 フィールドには 埋め込み キーだ。

3.ネットワーク・セグメンテーション

推論サーバーが公共のインターネットに直接さらされないようにしてください。アクセスは、入力をサニタイズし、認証を処理するバックエンド・サービスによって仲介されるべきである。

結論

CVE-2025-62164はAIセキュリティへの警鐘となる。我々はもはや「モデル」や「エンベッディング」を不活性なデータとして扱うことはできない。AIの時代に、 データはコードそして、それをデシリアライズするには、バイナリ実行ファイルを実行するのと同じレベルの精査が必要である。

AIインフラ上でペンテストを実施しているチーム（例えば ペンリジェント)、推論エンジンで公開されているシリアライゼーション・エンドポイントをチェックすることは、今やエンゲージメント・スコープの標準的な部分であるべきだ。

筆者注：AIのインフラを安全に保ちましょう。常に入力を検証し、シリアル化されたデータを信用せず、vLLMのバージョンを最新の安定リリースに固定してください。