CVE-2025-62164は、以下のような深刻度の高い脆弱性である。 ブイエルエルエム最も広く使われているオープンソースのLLM推論エンジンの1つである。この問題は コンプリーションAPI サーバーが ユーザー提供のプロンプト埋め込み.影響を受けるバージョン (0.10.2から0.11.1を除くを使用してテンソルをデシリアライズする。 トーチ.ロード() 強力な検証なしに。細工されたスパース・テンソルは、それをすり抜けることができる。 高密度化中の境界外書き込みこれは確実に Worker をクラッシュさせ、適切な条件下ではリモートコード実行にエスカレートする可能性があります。プロジェクトは vLLM 0.11.1. (NVD)

このCVEが通常のAIスタックバグと異なる点は2つある。第一に データプレーン欠陥管理者のUIや設定ミスではなく、ユーザーが完了を求めるのと同じ推論エンドポイントを通じて到達可能な悪用経路だ。第二に 安全でないデシリアライズと上流の動作ドリフトこのコンボは、LLMのインフラが成熟するにつれて現れ続けている。

スタックにおけるvLLMの位置 - そしてその位置がリスクを増幅させる理由

vLLMは事実上、スループットを最適化した推論レイヤーである。チームはこれを、パブリックなSaaS APIとして、エンタープライズ・ゲートウェイの背後に、あるいはマルチテナント・エージェント・システムのサービング・バックエンドとしてデプロイする。これらすべてのレイアウトにおいて、vLLMはインターネットに近く、GPUリソースに近い。これはパフォーマンス・エンジニアリングのように聞こえますが、次のような意味もあります。 低特権API呼び出し元が特権コードパスに到達する可能性がある. (ウィズ・アイオ)

だから、爆発半径は微妙ではない。クラッシュ可能なエンドポイント1つで、GPUの餓死、キューの蓄積、オートスケーラーの解約、ノイジー・ネイバー・インシデントが発生する可能性がある。エクスプロイトがRCEに安定化すれば、推論フリートはサプライチェーン侵入の正当な足がかりとなる。

一段落に見る脆弱性

脆弱な vLLM バージョンの Completions エンドポイントでは、クライアントが以下を渡すことができます。 プロンプト埋め込み vLLMは、これらのテンソルを生テキストの代わりに再構成する。 トーチ.ロード() 十分な完全性、型式、構造チェックがない。それ以来 PyTorch 2.8.0 はデフォルトでスパーステンソルの整合性チェックを無効にする悪意のあるスパーステンソルは、内部的な境界保護をバイパスし、次のようなトリガーを引き起こす可能性がある。 境界外メモリへの書き込み to_dense() とは.すぐに再現可能な結果は リモートDoS (ワーカークラッシュ）。有利なメモリレイアウトと制御があれば、同じプリミティブを次のようにすることも可能です。 ホストのRCE. (NVD)

根本原因解明：「便利なエンベッディング・パス・スルー」がメモリ破壊になった理由

パブリック・エンドポイント上のデシリアライズ・シンク

トーチ.ロード() は強力に設計されている。これは、信頼できるソース（チェックポイント、内部パイプライン）からテンソルやオブジェクトグラフをリストアするためのものだ。vLLMの場合、API呼び出し元が入力可能なフィールドで使用される。これは信頼境界を "内部モデルアーティファクト "から "信頼されていないインターネット入力 "にシフトさせる。(NVD)

この問題は、古典的なpickle-RCEの連鎖ではなく、メモリ破壊として現れているが、根本的な間違いは同じである： 複雑なバイナリ構造を単なるリクエストパラメータのように扱う.

PyTorch 2.8.0のビヘイビア変更は火種だった

vLLM 勧告と NVD はどちらも PyTorch の変更点である、スパーステンソルの整合性チェックがデフォルトでオフになったことに端を発しています。以前は、不正なスパーステンソルはコードパスが高密度化に到達する前に拒否される可能性が高かった。チェックが無効になったことで、vLLM の事前検証の欠如が一貫した方法で悪用されるようになりました。(NVD)

これは、AIのインフラ・セキュリティに有効なメンタル・モデルである： 上流のデフォルトは、"安全ではないが休眠状態 "を "安全ではなく、武器になり得る状態 "に無言で変えてしまう。

インパクト・リアリティ・チェックDoSは保証され、RCEは天井だ

すべての公文書は次のように書いている。 リモートDoSは信頼できる.単一の不正なリクエストはワーカーを殺すことができ、 繰り返されるリクエストはフリートが不安定になる可能性があります。(ゼロパス)

RCEは次のように説明される。 ポテンシャル には理由がある。メモリ破壊はその経路を提供するが、武器化できるかどうかは、アロケータの動作、ハードニング・フラグ、コンテナの境界、攻撃者が破壊された領域をどれだけコントロールできるかにかかっている。また CISA KEV上場なし 2025年11月25日現在、広く確認されているエクスプロイト・チェーンは存在しないが、データプレーンのメモリ破損を「DoSのみ」と扱うのは間違いである。(ウィズ・アイオ)

影響を受けるバージョンと修正状況

(NVD)

誰が最初にパニックになるべきか重要な脅威モデル

実用的な優先順位付けのレンズが欲しいのであれば、エンベッディングがシステムに入り込む可能性のある場所について考えてみよう。

公開vLLMエンドポイントは、明らかにリスクの高いケースだ。呼び出し側にAPIキーが必要だとしても、そのハードルは低い。基本的なアクセス権を持つ普通のユーザーであれば、ワーカーをクラッシュさせるのに十分かもしれない。(ウィズ・アイオ)

次はマルチテナント型の「LLM as a Service」プラットフォームだ。危険なのは、エンベッディングが それとなく - ツールチェーン、プラグイン、エージェントフレームワーク、または最適化としてエンベッディングを通過させるアップストリームサービスを通して。テキスト以外のペイロードを受け入れる場所が増えれば増えるほど、信頼境界はより複雑になります。

最後に、コミュニティ・デモや教育用デプロイメントを軽視してはならない。これらは認証されず、監視が行き届かず、所有者がその存在を忘れてから長い間公開されることがよくある。

被ばくを確認する安全な方法（危険なプロービングなし）

最速のトリアージはバージョン・ベースだ。

python -c "import vllm; print(vllm.__version__)"
0.10.2 <= version < 0.11.1 の場合、# に影響します。

(NVD)

作戦的には、以下のパターンを探す。 ワーカーのセグメンテーション違反や突然の再起動 これは、異常に大きな、あるいは構造的に奇妙な完了要求と関連している。実際には、クラッシュのスパイクが最初に現れる。(ゼロパス)

無害なカナリアチェック（標準的な補完、エンベッディングのパススルーなし）は、パッチを当てる際の安定性のベースラインとして有用だ：

インポート リクエスト、json、時間

HOST = "https:///v1/completions"
headers = {"Authorization"："ベアラ "}。

ペイロード = {
    "model"："your-model-name"、
    "prompt"："ヘルスチェック"、
    "max_tokens"：4
}

for i in range(5)：
    r = requests.post(HOST, headers=headers, data=json.dumps(payload), timeout=10, verify=False)
    print(i, r.status_code, r.text[:160])
    time.sleep(1)

迅速なパッチ、そしてデータプレーンの強化

にアップグレードするだけである。 vLLM 0.11.1以降.それ以外はその場しのぎだ。(NVD)

その後は、"バイナリ推論入力 "をリスクの高いシンクとして扱う。もし本当に埋め込みパススルーが必要な製品であれば、厳格なスキーマ検証でゲートしてください：期待されるテンソルのd型、形状、最大サイズを強制し、明示的にサポートしない限りスパースフォーマットを禁止してください。間抜けなallowlistでも、このCVEが依存する特定のクラスの不正な構造をブロックすることができます。(ウィズ・アイオ)

vLLMワーカーは最小権限で実行し、可能な限り読み取り専用ファイルシステム、センシティブなホストマウント、コンテナseccomp/AppArmorプロファイルで実行する。もし誰かがメモリ破壊を連鎖させてコードを実行するようなことがあれば、秘密やラテラルパスに到達できないボックスに閉じ込めたい。

なぜCVE-2025-62164はAIセキュリティにとって重要なのか？

この事件は、AIセキュリティがいかに古典的なウェブアプリのプレイブックから離れつつあるかを示す好例である。

新しいフロンティアは モデルサービス・データプレーンテンソル、エンベッディング、マルチモーダルブロブ、シリアライズされたアーティファクトは、速くて便利なのでAPIを経由して移動する。また、構造的に豊かで壊れやすく、パラノイアを持たずにデシリアライズすると、破損バグが発生しやすい。

また、LLMスタックのリスク表面は次のようなものであることも忘れてはならない。 作曲的vLLMがスパーステンソルの安全性を "発明 "したのではなく、PyTorchのデフォルトが変更され、下流の検証レイヤーの欠落がその変更をCVEに変えたのだ。推論エンジニアリングは今、カーネルチームが当然のように行っているのと同じレベルの依存性の精査を必要としている。

PoCが混乱したり遅れたりした場合の管理された検証

AIインフ ラのCVEは、安定した公開PoCの前に到着することが多い。あるいは、実稼働クラスタに向けるにはリスクが高すぎるPoCとともに到着することもある。擁護可能なアプローチは、より安全なループを産業化することである：権威ある情報→仮説→ラボのみの検証→監査可能な証拠。

Penligentスタイルのエージェント型ワークフローでは、エージェントにvLLMアドバイザリーとNVDレコードを取り込ませ、正確な暴露条件（バージョン、エンベッディングパス、PyTorchの仮定）を導き出し、次のようなデータを生成することができます。 最小リスク検証計画 隔離されたレプリカでのみ実行されます。そうすることで、プロッドGPUを賭けることなく、バージョンのフィンガープリント、クラッシュシグネチャ、パッチ前後の差分など、本当の証明が得られる。(NVD)

同様に重要なのは、エビデンス・ファーストの報告によって、緊急性をオペレーションのリーダーに説明しやすくなることだ。「ブログに書いてあったからパッチを当てました」では、インシデントレビューに耐えられない。「CVE-2025-62164のPoC: vLLMのコンプリーション・データプレーンのバグがエンベッディングを攻撃対象にしている。