GPUStack（GPUクラスタでAIモデルを動かし、GPUのインスタンスを管理するオープンソースの管理ソフト）の、認証なしに管理者として操作できる脆弱性の解説です。何が起きるのか・影響範囲・対応策を、攻撃の再現手順は伏せて防御目線でまとめます。
- CVE
- CVE-2026-102895（GitHub勧告 GHSA-gj9m-f8ph-pmhr）
- 重大度
- CVSS v3.1 9.8（Critical）。勧告・CVEの記録・NVDで同じ値
- 種別
- 不適切な認証（CWE-287）。勧告は、なりすましによる認証回避（CWE-290）、接続元の検証の誤り（CWE-346）も挙げている
- 前提条件
- 未認証。GPUStackに到達できればよい。勧告によると既定の設定が対象
- 対象
- pip版 gpustack 2.2.0未満
- 修正
- gpustack 2.2.0
- 公開日
- 勧告：2026年7月31日／CVE：2026年11月4日
- 悪用状況
- 勧告が実環境での悪用を報告。CISA KEV 追加：2026年11月9日（対応期限 11月12日）
放置の危険度
勧告によると、認証なしに、ユーザー・モデル・workerの設定を変更でき、どの接続元からでも使える管理者APIキーを作れます。workerやクラウド事業者の認証情報も読み取られ、管理者専用の機能と組み合わせるとworkerホスト上でコードが実行されます。勧告によると、実環境での悪用が観測されています。CISAは、このKEVの項目でフォレンジックの優先調査（Forensic Triage）を「必要」としています。
どんな脆弱性か
GPUStackは、既定の設定（force_auth_localhost が false）では、同じマシン上からのリクエスト（ループバック）を、内蔵の管理者として扱います。ローカルで使うときに認証の手間を省く作りです。問題は、この「同じマシンからか」を判断する材料が、外から操作できる点にあります。
勧告によると、認証なしに管理者になれる経路は2つあります。1つ目は、同じホストに置いたリバースプロキシです。プロキシがGPUStackへ中継すると、外部からのリクエストも、GPUStackからは接続元がループバックに見えます。自前で立てる一般的な構成で、ヘッダーも認証情報も要りません。2つ目は、リクエストの転送ヘッダーで、勧告によると、利用者が付けた値で接続元をループバックと見せかけられます。当サイトは具体的な悪用方法を記載しません。
更新前（2.2.0未満）
- 接続元がループバックなら、認証なしで管理者になる
- 同じホストのリバースプロキシ経由だと、外部の通信もループバックに見える
- 転送ヘッダーで接続元を偽れる
更新後（2.2.0）の変更点
- ループバックを管理者とみなす経路を削除
- クライアントIPと転送ヘッダーの扱いを強化
- 実クライアントIPのヘッダーは、認証済みの信頼できるゲートウェイからだけ受け付ける
影響範囲
| 項目 | 内容 |
|---|---|
| 製品 | GPUStack（オープンソースのGPUクラスタ管理ソフト） |
| 対象のパッケージ | pip の gpustack |
| 影響を受ける版 | 2.2.0未満（勧告・CVEの記録とも） |
| 修正版 | 2.2.0 |
| 実害の報告 | 勧告：v2.1.1の環境で実環境での悪用を観測 |
| 起こり得ること | 管理者としての全操作（ユーザー・モデル・workerの変更）、管理者APIキーの作成、workerとクラウド事業者の認証情報の読み取り、worker上でのコード実行（いずれも勧告・KEVの記載） |
- 勧告によると、既定の設定が対象です。
- 勧告が挙げる影響パッケージはpipのgpustackだけです。コンテナーイメージなど別の形で導入している場合は、提供元の情報で版を確認してください。
自分が対象か確かめる方法
GPUStackの版を確認する
導入しているgpustackの版を確認します。2.2.0未満なら対象です。本番・検証・開発の環境が複数あるなら、1つずつ確認します（資産棚卸しチェックリスト）。
外から到達できるかを確認する
GPUStackのポート、またはその前段のリバースプロキシに、インターネットなど信頼できない範囲から到達できるかを確認します。勧告によると、同じホストのリバースプロキシ経由でも成立するため、「プロキシの裏にある」ことは安全の根拠になりません。
force_auth_localhost の設定を確認する
設定 force_auth_localhost が true かどうかを確認します。勧告によると、既定は false で、この場合に脆弱性の経路が開きます。
今日やること
2.2.0へ更新する（最優先）
gpustackを2.2.0以降へ更新します。KEVの対応期限は2026年11月12日です。
更新できるまでの間は、入口を絞る
勧告の回避策は次のとおりです。更新の代わりにはなりません。
・設定 force_auth_localhost を true にして、ループバックからでも認証を求める。
・リバースプロキシやゲートウェイが、外部の通信をループバックと見せないようにし、利用者が付けた X-GPUStack-Real-IP ヘッダーをエッジで除去する。
・APIを信頼できない網に置かず、VPNやエッジの認証の内側に置く。
更新後に、管理者APIキーを棚卸しする
勧告によると、作られた管理者APIキーは、以後どの接続元からでも使えます。更新しても消えないので、存在するAPIキーを一覧し、作成者・作成日時に見覚えのないものを削除します。更新前の期間に作られたキーを重点的に見てください。
認証情報を失効・再発行する
勧告は、workerの認証情報とクラウド事業者の秘密情報が読み取られ得ると説明しています。GPUStackに登録していた、workerの接続用の情報、クラウド事業者のキー、モデルの取得用トークンなどを、失効して再発行します。当サイトの補足として、悪用の痕跡が見つからなくても、再発行を勧めます。進め方は 脆弱性対応の実務手順 と セキュリティ超入門：.env と APIキー にまとめています。
設定とworkerを点検する
見覚えのないカスタムのバックエンド、ユーザー、モデルの設定がないかを確認します。worker上で、見覚えのないプロセスや外向きの接続がないかも確認します。悪用が確認されているので、見覚えのない設定は侵害の痕跡として扱ってください。不審なものが見つかったら、そのworkerを隔離し、再構築を検討してください。
悪用状況
- 勧告によると、v2.1.1のデプロイに対する実環境での悪用が観測されています。実悪用は第三者の報告者が報告したとされています。
- CISAのKEV（悪用が確認された脆弱性の一覧。版 2026.11.09）に、2026年11月9日に追加され、対応期限は11月12日です。ランサムウェアでの利用は「不明」、フォレンジックの優先調査は「必要」とされています。
- NVDの記録は、ステータスが Analyzed（分析済み）です。CVSS v3.1は9.8で、勧告・CVEの記録と同じです。
- 脆弱性そのものは、複数の報告者が、それぞれ独立に報告したと勧告にあります。
当サイトの視点：「社内だから」「プロキシの裏だから」で無認証にしない
この脆弱性は、実装の細かい誤りというより、設計の前提の問題です。接続元が自分のマシンなら本人、という前提は、リバースプロキシを置いた時点で崩れます。しかも、同じホストに置くリバースプロキシはHTTPS化や公開のために広く使われる構成で、「ちゃんと守っているつもり」の構成が、そのまま入口になります。
AI基盤の管理画面は、モデルの実行環境、GPUの資源、クラウドの認証情報を一手に握っています。そこが無認証で通ると、被害は1台では終わらず、クラウドの認証情報を通じて外へ広がります。管理画面や管理APIは、置き場所や接続元ではなく、必ず認証で守ってください。同じ種類の問題は、転送ヘッダーを信用する設計でも起きます（XFFスプーフィングと信頼するプロキシ）。更新後は、パッチを当てただけで終わらせず、作られたAPIキーと読み取られ得る認証情報を片付けるところまでが対応です。
出典
- GPUStack — GHSA-gj9m-f8ph-pmhr：Authentication bypass via trusted loopback source（2026年7月31日公開。対象・修正版・回避策・悪用の報告）
- CVE.org — CVE-2026-102895（2026年11月4日公開。2.2.0未満・CVSS 9.8）
- NVD — CVE-2026-102895（ステータスは Analyzed）
- CISA KEV — Known Exploited Vulnerabilities Catalog（2026年11月9日追加・対応期限 11月12日）
最終確認：2026年11月10日。