GPUStack（ローカルや自前のGPUサーバーでAIモデルを動かす管理ツール）を使っている人は、まず次を確かめてください。
- 動いているGPUStackが2.2.0未満なら、2.2.0以降へ更新する（公式アドバイザリーの修正バージョン）
- サーバーを先に更新し、そのあとワーカーを更新する（公式のアップグレード手順）
- インターネットから届く場所に置いていたなら、更新のあと、管理者のAPIキーやワーカー・クラウド側の秘密情報に不審なものがないかを確かめる
GPUStackには、認証をすり抜けて管理者として操作できてしまう脆弱性CVE-2026-102895（GitHub Security Advisory GHSA-gj9m-f8ph-pmhr）があります。2.2.0未満が対象で、2.2.0で修正されています。悪用が確認されており、米CISAの既知の悪用脆弱性カタログ（KEV）にも2026年11月9日に追加されました。米政府機関向けの対応期限は2026年11月12日です。
11月10日8時27分（日本時間）時点の、GitHubのセキュリティアドバイザリー、OSV、CISAのKEV、GPUStackのアップグレード手順にもとづく内容です。
結論：2.2.0未満なら更新する
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-102895 |
| 対象 | GPUStack 2.2.0未満 |
| 修正 | 2.2.0以降 |
| 深刻度（GitHub） | Critical（CVSS 9.8） |
| 悪用 | 確認あり（アドバイザリー。v2.1.1での観測例あり）。CISAのKEVに2026年11月9日追加 |
| やること | サーバー→ワーカーの順で2.2.0以降へ更新。更新前にデータベースのバックアップを推奨（公式） |
サーバーを管理するパソコンのウイルス対策も見直すなら、セキュリティソフトの比較で、更新料と使える台数を確かめられます。
どんな脆弱性か
公式アドバイザリーによると、2.2.0より前のGPUStackでは、リクエストの送信元をループバック（127.0.0.1）と見なした場合に、既定設定のまま管理者として扱う動きがありました。同じホスト上のリバースプロキシ経由の接続や、クライアントが付けたX-GPUStack-Real-IPヘッダーなどで、認証なしに管理者権限が付くことがあります。
その結果、次のような操作ができてしまう、と説明されています。
- ユーザー・モデル・ワーカー・設定の一覧や変更
- 管理者のAPIキーの作成（あとからどの送信元からも使えるもの）
- ワーカーの認証情報や、クラウド／プロバイダーの秘密情報の読み取り
- 管理者向け機能（例：
POST /v2/inference-backends/from-yaml）を通じた、ワーカー上でのコード実行につながる操作
アドバイザリーでは、v2.1.1の環境で実際に悪用された例（攻撃者が作ったカスタムバックエンド）も報告されています。攻撃の手順は書きません。自分の環境が対象かと、更新するかを確かめることが先です。
いまのバージョンの確かめ方
Dockerで動かしている場合は、コンテナが使っているイメージのタグを見ます。
sudo docker ps --filter name=gpustackIMAGEの列が gpustack/gpustack:v2.2.0 のように2.2.0以降なら、このCVEの修正バージョンです。タグが v2.1.1 など2.2.0未満、または古いイメージのままなら更新が必要です。コンテナ名が違う場合は、自分の環境の名前に読み替えてください。
Helmで入れている場合は、リリースのチャートバージョンがGPUStackのリリースと対応します（公式のHelmアップグレード手順）。--version 2.2.0のようにバージョンを固定する案内があります。
更新する（Docker）
公式の「Upgrade via Docker」によると、対象はGPUStack v2.0以降です。更新のまえにデータベースのバックアップを強く推奨しています。組み込みのPostgreSQLを使っている場合、コンテナ内の次の場所を止めたうえで退避します。
/var/lib/gpustack/postgresql/data外部データベースを使っている場合は、そのデータベース側の手順に従ってください。更新はサーバーを先に行い、そのあとワーカーです。同じ引数とボリュームで、新しいイメージのコンテナを起動します。例（タグは2.2.0以降を指定）：
docker pull gpustack/gpustack:v2.2.0
docker stop gpustack
docker rm gpustack
docker run -d --name gpustack \
--restart unless-stopped \
-p 80:80 \
--volume gpustack-data:/var/lib/gpustack \
gpustack/gpustack:v2.2.0docker runの引数は、いま動いているサーバーと同じ内容に合わせてください。公式手順の例では省略記号で示されています。インストール時の引数が分からないときは、更新前に sudo docker inspect gpustack で確認してください。
Docker Composeで入れている場合の公式例は、リポジトリで目的のリリースタグ（そのバージョン）に切り替えたあと、composeでpullして再作成する、という流れです。
cd gpustack
git fetch --tags
git checkout v2.2.0
cd docker-compose
sudo docker compose -f docker-compose.server.yaml pull
sudo docker compose -f docker-compose.server.yaml up -d更新する（Helm）
公式のHelm手順は、GPUStack 2.2.0以降向けです（Helmで入れられるようになった最初のバージョン）。それより前は、Dockerなど別の入れ方の更新手順を見てください。チャートのバージョンはGPUStackのリリースに合わせ、--versionでバージョンを固定します。インストール時の values を再利用してください。
helm upgrade gpustack oci://registry-1.docker.io/gpustack/gpustack-chart \
--namespace gpustack-system \
--version 2.2.0 \
-f values.yamlワーカー側（Dockerクラスターなど）も、サーバーと同じバージョンのイメージに揃えます。手順は公式の「Upgrade a Cluster Deployment」を見てください。
すぐ更新できないあいだの注意
2.2.0未満では、回避策として force_auth_localhost=true（ループバックにも認証を求める）が使えます。2.2.0以降ではループバックを管理者とみなす経路が取り除かれているため、CLIの --force-auth-localhost は非推奨で、指定しても動きは変わりません。根本対応は2.2.0以降への更新です。
アドバイザリーには、あわせて次の回避策もあります。
- リバースプロキシやゲートウェイ側で、外部からの通信がループバック扱いにならないようにし、クライアントが付けた X-GPUStack-Real-IP を端で取り除く
- APIを信頼できないネットワークに直接出さない（VPNや手前の認証など）
更新のあと確かめること
アドバイザリーは、認証なしで管理者のAPIキーを作られたり、ワーカーやクラウド／プロバイダーの秘密情報を読まれたりしうると説明しています。インターネットに出していた環境や、不審な動きがあった環境では、更新のあと次を確かめてください。
- 管理者向けのAPIキーに、覚えのないものがないか。あれば無効化や作り直しを検討する
- ワーカーの認証情報や、クラウド側の鍵・トークンに不審な追加や利用がないか
- 身に覚えのない推論バックエンドや設定変更がないか
CISAのKEVでは、ベンダーの案内に沿った緩和と、該当する場合の被害の調べ方にも触れています。自組織の方針に合わせてください。
よくある質問
pipのパッケージだけ更新すればよいですか？
GPUStackの入れ方によって違います。DockerやHelmで動かしているなら、公式のアップグレード手順（イメージまたはチャートの更新）に従ってください。READMEのクイックスタートもDockerを前提にしています。
latestタグでもよいですか？
公式のDockerアップグレード例には latest とバージョンタグの両方があります。再現性のため、Helm手順と同様に 2.2.0 以降の具体的なタグを指定する方法が分かりやすいです。開発中のmainやrcへのアップグレードは、公式が非推奨としています。
攻撃の詳しい手順は？
書きません。対象バージョンの有無と、公式どおりの更新・鍵の確認が先です。
コメント