AI基盤vLLMにAPIキー回避の欠陥 CVE-2026-48746ほか、0.22.1へ更新を

AIの大規模言語モデル（LLM）を高速に動かすための定番ソフト「vLLM」に、危険度の高い欠陥が2件公開されました。1つ目は、設定したAPIキーを回避して誰でもAIのAPIを使えてしまうCVE-2026-48746（CVSS 9.1）。2つ目は、Dockerでビルドする際に第三者のプログラムが紛れ込むCVE-2026-54232（CVSS 8.8）です。いずれも2026年6月22日の公開です。

vLLMは、自社のサーバーでLLMを動かして「OpenAIと同じ形式のAPI」を提供できるツールで、AI開発・運用の現場で広く使われています。修正は0.22.0（認証回避）と0.22.1（依存混同）で行われており、0.22.1以降へ更新すれば両方とも解消できます。

この欠陥は誰に、どんな被害をもたらすのか

とくに広く影響しうるのが、APIキー回避（CVE-2026-48746）のほうです。狙われるのは、vLLMのAPIサーバーを公開していて、保護を「APIキーだけ」に頼っている運用者です。vLLMには「このキーを持つ人だけがAPIを使える」という設定（--api-keyやVLLM_API_KEY）があり、多くの現場はこれで守っているつもりになっています。

ところがこの欠陥を突くと、攻撃者はそのAPIキーを知らなくても、認証チェックをすり抜けてvLLMのAPIを自由に使えてしまいます。ログインも、利用者の操作も要りません。鍵のかかった扉だと思っていた入口が、実は脇から素通りできた、という状態です。

被害は主に三つの形で出ます。第一に、LLMの実行には高価なGPUが要るため、タダ乗りで大量にリクエストを投げ込まれ、計算資源の浪費・コスト爆発や、サービスが重くなる・止まる事態を招きます。第二に、そのvLLMに載せているモデルや、組み込んだ指示文（システムプロンプト）、社内データに不正にアクセスされる恐れがあります。第三に、社内向けに立てたLLMが、外部の誰かに勝手に使われ、機密のやり取りや不適切な生成の踏み台にされかねません。だからこそ、後述する更新と公開範囲の見直しが急がれます。

そもそもvLLMとは何か

vLLMは、LLMを高速かつメモリ効率よく動かすための推論・配信エンジンです。米カリフォルニア大学バークレー校の研究室で生まれ、いまは2000人を超える開発者が関わる、GitHubで約7.5万のスターを集めるAIインフラの定番です。最大の特徴は「OpenAI互換API」を備える点で、OpenAIのAPIを呼ぶように書いたプログラムの接続先を、自社で動かすvLLMにそのまま差し替えられます。

自社サーバーでLLMを動かしたい企業・研究者にとって便利な土台である一方、APIサーバーとして外部に口を開ける以上、その入口の守りが破られれば影響は大きくなります。vLLMはこれまでも継続的に脆弱性が見つかり修正されてきた製品で（たとえば動画処理経由の遠隔コード実行 CVE-2026-22778など）、利用者には更新を追い続ける運用が求められます。

技術的に何が起きているのか

CVE-2026-48746：APIキーを回避できる認証バイパス（CVSS 9.1）

分類はCWE-444（HTTPリクエスト/レスポンス・スマグリング）です。セキュリティ企業X41 D-Secのソースコード監査で発見されました。vLLMの認証ミドルウェアは、保護対象（/v1のAPI）かどうかをURLのパスで判定しています。ところがこのパスは、前段のWebサーバー（ASGI）とStarletteの信頼関係をもとに組み立て直されるため、攻撃者はその組み立てのズレを突いて、認証チェックの対象外であるかのように見せかけられます。結果として、設定済みのAPIキーを通さずに/v1のAPIへ到達できてしまいます。攻撃はネットワーク経由・認証不要・利用者操作不要で、対象は0.3.0〜0.22.0未満、修正は0.22.0です。

CVE-2026-54232：Dockerビルド時の依存混同でroot権限コード実行（CVSS 8.8）

こちらはCWE-427（制御されていない検索パス要素）、いわゆる「依存混同（dependency confusion）」です。vLLMのDockerfileは、`flashinfer-jit-cache`というパッケージを独自のインデックスから取得しますが、これはPyPI（標準のPythonパッケージリポジトリ）に登録されておらず、しかも全体で「最も条件に合うものを優先する」緩い設定（UV_INDEX_STRATEGY="unsafe-best-match"）が効いていました。このため、攻撃者が同じ名前のパッケージをPyPIに登録しておくと、Dockerイメージのビルド時にそちらが取り込まれ、ビルドを行うマシン上でroot権限のまま任意コードを実行できてしまいます。悪用にはイメージをビルドさせるという条件（UI:R）が要りますが、CI/CDで自動ビルドしている環境では現実的な脅威です。修正は0.22.1です。

いま分かっていること・まだ分からないこと

いま何をすべきか

最優先は、vLLMを0.22.1以降に更新することです。これで認証バイパスと依存混同の両方が解消されます。0.22.1より前を使っているなら、検証用・本番用を問わず対象だと考えてください。

更新までの応急策として、APIキー回避のほうは、vLLMのAPIサーバーをインターネットに直接公開せず、社内ネットワークやVPNの内側に置き、前段に本物の認証（リバースプロキシやAPIゲートウェイ）を挟むのが有効です。「APIキーさえ設定すれば公開して大丈夫」という前提自体を見直すべき欠陥でした。依存混同のほうは、自分でDockerイメージをビルドしている場合に効く話で、取得元インデックスを明示・固定し、パッケージのハッシュ検証を有効にする、ビルドに使う名前空間を自社で押さえる、といった対策が効きます。OSSの依存関係を継続的に点検する仕組みを持っておくと、この種の供給網の問題に素早く気づけます。

まとめ

vLLMに公開された2件の欠陥のうち、CVE-2026-48746は、設定したAPIキーを回避して認証なしでAIのAPIを使われてしまう、CVSS 9.1の認証バイパスです。CVE-2026-54232は、Dockerビルド時に第三者のパッケージが紛れ込み、ビルドマシンでroot権限のコード実行を許す依存混同（CVSS 8.8）です。どちらも0.22.1への更新で解消できます。

自社でLLMを動かす構成が当たり前になるなか、その入口（APIサーバー）と作り方（ビルド工程）の両方が狙われた格好です。更新に加えて、APIの公開範囲と、ビルドで取り込むパッケージの素性を、この機会に点検しておくことをおすすめします。

参照元

• ・NVD — CVE-2026-48746
• ・NVD — CVE-2026-54232
• ・アドバイザリ GHSA-94f4-hr76-p5j6（CVE-2026-48746、X41 D-Sec）
• ・アドバイザリ GHSA-jrf6-vqxq-pjv2（CVE-2026-54232）
• ・vLLM 公式セキュリティアドバイザリ一覧（GitHub）
• ・CWE-444（HTTPスマグリング） / CWE-427（依存混同）