自社のAI基盤にGPUStackを使っている場合、まず稼働中のサーバーの版を確認してください。CISAは2026年11月9日、認証回避の脆弱性CVE-2026-102895を悪用確認済み脆弱性カタログ（KEV）へ追加しました。このカタログの公開時刻は日本時間11月10日4時54分です。今回のニュースは悪用リストへの追加であり、修正プログラムが初めて出たという意味ではありません。CISA公式カタログ
対象は2.2.0未満。「localhostだから安全」とは限らない
開発元の勧告ではGPUStack 2.2.0未満が対象、2.2.0がこの脆弱性の修正版です。旧版の既定値では、ローカルから来たと判定した要求を管理者として扱う処理があります。同じホスト上のリバースプロキシから転送される通信もローカルに見える場合があり、インターネット側から直接GPUStackへ接続できなくても確認が必要です。開発元は2.1.1での悪用を報告していますが、これだけで個々の環境が侵害されたとは判断できません。開発元のセキュリティ勧告
更新前に版・接続経路・保存先を記録する
- 稼働している版を調べる。管理しているコンテナのイメージタグや運用記録を確認します。新しいイメージをダウンロード済みでも、稼働中のコンテナが古ければ更新は完了していません。
- 接続経路を整理する。公開URL→プロキシ→GPUStack APIの順に、同じホストで動く箇所と認証を行う箇所を書き出します。
- 再作成に必要な設定を確保する。現在の起動コマンド、Composeファイル、設定ファイル、永続ボリュームの対応、対象ワーカーを記録します。トークンなどを共有チケットへ貼り付けないようにします。
- 保守時間とバックアップを用意する。内蔵PostgreSQLを使う標準構成では、サーバーを停止してコンテナ内の
/var/lib/gpustack/postgresql/dataを対象にバックアップします。外部DBではそのDBの手順に従います。
公式のDocker更新手順はv2.0以降が対象です。0.7以前などの古い構成はデータベースや実行環境の移行が関わるため、同じコマンドをそのまま適用せず移行ガイドを確認してください。
Docker構成はサーバー、次にワーカーを更新
運用環境に合う安定版を選びます。2.2.0はこのCVEの最低修正版であり、最新版やすべての問題を修正する版という意味ではありません。開発版やRCを通常運用の更新先にしないようにします。
- 選んだ修正済み安定版のイメージを取得します。
- バックアップと復元手段を確認してから、既存サーバーを停止します。
- 従来の設定・起動引数・永続ボリュームを維持し、新しいイメージでサーバーのコンテナを再作成します。
- サーバーが正常起動したら、ワーカーをサーバーと同じ版へ更新します。
既存のボリュームを誤って消さないこと、docker pullだけで終わらせないことが重要です。Composeを使う構成は対象リリースと設定を確認したうえで、イメージ取得とコンテナ再作成を行います。公式Docker更新手順
Dockerクラスターのワーカーは、更新後の管理画面でClusters→Add WorkerのRun commandを確認できます。既存の引数と保存先を維持して更新し、正常接続を確認します。登録済みKubernetesクラスターには別の再登録・マニフェスト適用手順があります。方式を混ぜず、クラスター別の更新手順に合わせて進めます。
すぐ更新できない旧版の暫定策
開発元は、旧版でforce_auth_localhost=trueを設定してローカル要求にも認証を求めること、利用者が送ったX-GPUStack-Real-IPを信頼境界で除去すること、VPNや入口の認証でAPIの公開範囲を制限することを案内しています。ヘッダーを消すだけでは、同一ホストのプロキシ経由の問題が残ります。暫定策は修正版への更新計画と組み合わせてください。公式の回避策
現行のCLI資料では--force-auth-localhostは非推奨で、互換性のために残る無効な設定です。修正後はローカル要求も認証必須なので、この設定の警告を見て認証が解除されたと誤解しないでください。現行CLIの説明
更新後に確認する項目
稼働中のサーバー・ワーカーの版、ワーカーの接続状態、通常の推論処理を確認します。たとえば毎朝ローカル接続でモデル状態を集計する社内スクリプトがあれば、更新後に認証エラーになる可能性を考え、適切な認証情報を使う構成へ直します。過去の認証不要動作を復活させる対応は避けます。
また、想定外のユーザー、管理者APIキー、カスタム推論バックエンドがないか、担当者が運用記録と照合します。不審な変更があれば証拠を保存して組織のインシデント対応へ引き継ぎます。更新したという事実だけで、すでに作成されたキーや漏えいした認証情報まで解決したとは扱えません。通常の更新完了確認と、侵害の有無の調査を分けて記録してください。
コメント