GPUStackに認証回避、管理者権限が無認証で開く。CVE-2026-102895は悪用確認済みで、CISAの期限は11月12日

まず初めに

「身内は信用する」という設計は、玄関の鍵を郵便受けの内側に掛けておくようなものだ。家の中にいる人間しか触れない前提なら便利だが、その郵便受けに外から手が届いたら終わる。今回の欠陥はまさにそれで、「この接続は自分自身からだ」という自己申告を、サーバーが疑いもなく信じてしまった。AIの計算資源を束ねる管理ソフトでそれが起きたのだから、被害の形も「GPUを全部持っていかれる」という分かりやすいものになる。

※個人の感想です

脆弱性の仕組み——「自分から」を装われると管理者になる

GPUStackは、複数のGPUを束ねてAIモデルの推論サービスやGPUインスタンスを提供するための、オープンソースのクラスター管理ソフトです。

開発元のセキュリティ勧告（GHSA-gj9m-f8ph-pmhr）によると、バージョン2.2.0より前のGPUStackでは、認証を担う処理（get_current_user）が、接続元がループバック（127.0.0.1、同じマシン自身）である場合に、組み込みの管理者アカウントとして扱っていました。この動作は、設定force_auth_localhostがfalseの場合に有効で、これは既定（デフォルト）の状態です。

問題は、外部からの接続でも「ループバックから来た」ように見せかけられた点です。勧告は、次の2つの経路を挙げています。

• 同じホスト上にあるリバースプロキシを経由した接続で、その接続元をループバックと誤認する
• 利用者が送るヘッダー「X-GPUStack-Real-IP」にループバックの値を入れることで、接続元を偽装する

成立すると、ネットワーク越しに、認証なしで管理者権限が得られます。

侵害されると何ができるのか

勧告が挙げる影響は、次のとおりです。

• 利用者、モデル、ワーカー、設定の一覧表示と変更
• 恒久的に使える管理者APIキーの新規発行（適用範囲は全権限を示す「*」で、発行後はどの接続元からでも有効）
• ワーカーの認証情報や、クラウド事業者等の秘密情報の読み取り
• 管理者専用機能「POST /v2/inference-backends/from-yaml」を通じた、ワーカーホスト上でのコード実行

つまり、単に画面を覗かれるだけの欠陥ではありません。管理者キーを1つ発行されてしまえば、脆弱性自体を塞いだ後も、そのキー経由で入り続けられます。深刻度はCVSS 3.1で9.8（Critical）、弱点の分類はCWE-287（不適切な認証）、CWE-290（なりすましによる認証回避）、CWE-346（出自の検証エラー）です。

勧告によれば、この脆弱性はバージョン2.1.1の実環境に対して、実際に悪用されていることが観測されています。攻撃者や被害件数は公表されていません。

同じ日にCISAのKEVへ追加された脆弱性には、OpenSSHの認証回避「SSHole」も含まれています。

対象と対策

項目	内容
対象	GPUStack 2.2.0より前の全てのバージョン
修正版	2.2.0
CISA KEV追加日	2026年11月9日
連邦機関の対応期限	2026年11月12日
ランサムウェアへの利用	不明（Unknown）

対策の中心は、2.2.0への更新です。直ちに更新できない場合の緩和策として、勧告はforce_auth_localhost=trueに設定し、ループバックからの接続でも認証を必須とする方法を示しています。あわせて、接続元のヘッダーを利用者側から書き換えられないよう、入口のプロキシでX-GPUStack-Real-IPを取り除くこと、管理APIを信頼できないネットワークへ公開しないことが有効です。

更新後に必ず確認したいのは、不審な管理者APIキーが発行されていないかです。前述のとおり、発行済みの管理者キーは脆弱性を塞いでも有効なまま残ります。利用者やモデル、推論バックエンドの設定に心当たりのない変更がないかも、併せて点検してください。CISAは、ベンダーの指示に従った緩和策の適用と、BOD 26-04に基づくフォレンジック・トリアージ（侵害の痕跡調査）を求めています。

自分の環境が対象かどうかの確かめ方

点検の手順は、大きく3つに分かれます。

1. GPUStackのバージョンを確認し、2.2.0より前であれば対象として扱う。検証用に立てた小規模な環境や、リバースプロキシの背後に置いた管理画面も例外ではありません。今回の欠陥は、まさにプロキシ経由の接続で成立する経路を含むためです。
2. 管理APIが、信頼できないネットワークから到達できる状態になっていないかを確認する。到達できる場合は、更新までの間も公開範囲を絞ることが先です。
3. 更新の前後で、管理者APIキーの発行履歴、利用者とモデルの変更、推論バックエンドの追加がないかを確認する。心当たりのない管理者キーがあれば、脆弱性の修正とは別に、そのキーの失効と、キーで触れた範囲の調査が必要です。

なお、勧告は「悪用が観測された」ことを示していますが、攻撃者、被害の規模、対象となった組織の属性は公表されていません。自組織で痕跡が見つからなかった場合でも、それだけで「攻撃を受けていない」と確定させることはできません。

IT Postの見方

IT Postでは、この件で最も重いのはCVSS 9.8という数字そのものより、「AIの計算資源を管理する層」に欠陥があった点だと考えます。GPUStackのような管理ソフトは、モデル、認証情報、クラウドの秘密情報、そしてワーカー上でコードを実行する権限まで、一か所に集約します。ここが開くということは、置いてあるGPUの数だけ被害が広がるということと同義です。

もう1つは期限の短さです。KEVの期限が追加から3日というのは異例で、CISAが「様子見を許さない」と判断した水準だと読めます。GPUを社内で束ねている組織は、製品名を知らなくても、開発チームが検証用に立てた管理サーバーが残っていないかを含めて、棚卸しをする価値があります。管理画面が社内向けだから安全、という前提は、今回の「ループバックなら管理者」と同じ種類の思い込みです。

※個人の感想です

今後どうなりそうか

次の確認点は、悪用の規模や攻撃者に関する追加情報、影響を受けた可能性のある環境への注意喚起の広がりです。GPUStack側から続報や追加の修正版が出た場合は、本記事を更新します。

IT Postでは、KEVへの追加が続く他の脆弱性についても、期限と対象を確認しながら取り上げます。