vLLMに脆弱性7件 0.31.0で修正、認証なしの入口からコード実行も

AIのモデルを動かすサーバーの部品「vLLM」に、7件の脆弱性があります。開発チームは2026年10月6日にGitHubで勧告を出し、10月21日にCVEの番号(CVE-2026-114049〜114055)が付きました。GitHubの脆弱性データベースとドイツのCERT-Bund(WID-SEC-2026-4076)も、同じ日に注意を出しています。

7件は、どれも10月5日に出た0.31.0で直っています。この記事の内容は、10月21日に勧告とGitHubの脆弱性データベースで確かめたものです。

7件の中身と入口

いちばん重いのはCVE-2026-114053で、GitHubの脆弱性データベースはCVSS 4.0で9.2(Critical)と評価しています。trust_remote_codeを有効にしている場合に、要求の中の値で、モデルの処理のコードのどの版を読み込むかを利用者が選べてしまいます。配っているモデルの保管先で、攻撃者が版を操れるときは、認証なしの/tokenizeの入口から、vLLMのAPIの処理の中でPythonのコードを実行できるとしています。

ほかの6件は、サーバーを止めたり、ほかの要求の内容に影響したりするものです。

• CVE-2026-114052: MOSS-Audioのモデルを配るとき、/tokenizeに値を送り続けると、メモリを使い切って処理が落ちる。この入口は--api-keyを通らない
• CVE-2026-114055: 画像や動画の処理の値(大きさやコマの数など)を大きくして、メモリを使い切らせる
• CVE-2026-114050: 偽のIDでキャッシュの中身をずらし、サーバー全体を落とす。認証なしで届く
• CVE-2026-114051: 1回の要求で、その後の生成がすべて止まる。/healthは正常を返し続けるため、気づきにくい
• CVE-2026-114054: キャッシュのキーを重ねて、ほかの要求の処理済みの画像を受け取る。ログインした利用者が対象
• CVE-2026-114049: ほかの利用者の要求の出力の範囲を狭める。認証なしの/invocationsなどから届く

評価は、出したところで違います。開発チームの勧告は、低い(1件)、中くらい(3件)、高い(3件)に分けています。GitHubの脆弱性データベースは、CVEを付けたVulnCheckの評価で、Critical 1件、High 5件、Medium 1件としています。悪用の記載はなく、CISAのKEVにも載っていません。

vLLMでは、10月19日に公表された別の9件もあり、こちらは0.32.0で直っています(vLLMに脆弱性 0.32.0で9件を修正、Ghostscript経由のコード実行も)。0.32.0に上げれば、今回の7件も含めて直ります。

影響する会社・しない会社

• 影響する: vLLMの0.31.0より前の版で、AIのモデルを配るサーバーを動かしている会社です。認証なしの入口から届くものが多いため、社内のネットワークの中でも、届く範囲が広いと危うくなります。
• 影響する: trust_remote_codeを有効にしてモデルを配っている会社です。CVE-2026-114053の条件に当たる可能性があります。
• 影響する: 研究や開発の部門が、情シスの知らないところで推論のサーバーを立てている会社です。版と公開の範囲を確かめる必要があります。
• 影響しない: vLLMを使っていない会社です。ほかのAIのサービスやクラウドの推論のサービスだけを使っている場合は、今回の7件の対象ではありません。

情シスが今日やること

1. 社内でvLLMを使っているサーバーを洗い出します。研究・開発・データ分析の部門に、AIのモデルを動かすサーバーを立てていないかを聞きます。
2. 見つかったサーバーの版を確かめ、0.31.0以上(できれば0.32.0以上)に上げる日を決めます。
3. 推論のサーバーが、インターネットや社内の広い範囲から届く状態になっていないかを確かめます。APIキーだけに頼らず、ネットワークで届く相手を絞ります。
4. trust_remote_codeを有効にしているかを確かめます。有効なら、配っているモデルの保管先を誰が書き換えられるかも確かめます。
5. サーバーが止まったり、応答が止まったりしたときに気づけるよう、/healthだけでなく、実際の生成の応答も見張る形にします。