GPUStackの認証回避が実悪用：ローカルLLM基盤の対象版・更新・APIキー点検

GPUStackは、複数のGPUやワーカーを管理し、AIモデルを配備・提供するためのオープンソースソフトウェアです。ワーカーは実際にモデルを動かす計算機側の役割で、サーバー側はユーザー、モデル、ワーカーなどを管理します。オンプレミスのほか、クラウドやKubernetesの構成でも使われます。

今回の問題は、LLMの回答品質やプロンプトインジェクションではなく、GPUStackの管理APIの認証処理です。「入力を外部の推論サービスに送らないこと」と「管理機能が無断で使われないこと」は、別々に守る必要があります。GPUStackを使わないローカルLLM環境まで、このCVEの対象になるわけではありません。

数値・対象版・実悪用の根拠は公式勧告です。リバースシェルは、侵入先から攻撃者側へ接続を作り、遠隔操作に使う仕組みです。ただし公表資料からは被害組織数、日本国内の被害、攻撃開始日時までは確認できません。CVSSは技術的な深刻度であり、自社で侵害が起きた確率ではありません。

localhost（ループバック）は、コンピューターが自分自身と通信するときの宛先です。問題のある実装では、既定値がfalseの設定force_auth_localhostのもとで、送信元がループバックと判断された要求を組み込み管理者へ昇格させていました。送信元の住所を、本人確認の代わりにしていたことが根本の問題です。

リバースプロキシは、利用者からの通信を受けて内部のアプリへ取り次ぐ受付です。GPUStackと同じホストに置くと、外部利用者の通信でもGPUStackから見た直接の相手が同じコンピューターになります。「受付から来たから社内の管理者だ」と扱ってしまう構図です。

公式勧告はこの2つを別々の経路として示しています。HTTPSで暗号化していても、認証の誤判定は防げません。またGPUStack自体をlocalhostに待ち受けさせても、プロキシが外部へ公開していれば「外部から到達できない」とは言えません。2.2.0ではループバックから自動的に管理者になる処理が削除され、IP・転送ヘッダーの扱いも強化されました。

これらは公式勧告が示す影響です。すべての環境で情報流出が確認されたという意味ではありません。ホスト上の実行権限は構成に依存するため、常にOSの最高権限を奪われるとも断定しません。一方、作成された管理者APIキーは以後の接続元にかかわらず利用できるとされ、更新だけで過去の侵入まで解消したと判断するのは危険です。

出典はv2.2.0リリース、公式勧告、CVEレコード、CISA公式公開データです。各公開日時から攻撃の開始時期は推測できません。本記事は「今日発見された脆弱性」ではなく、実悪用情報を受けた運用点検として扱っています。

1. 1GPUStackを管理する担当者と資産を特定する。試験用・社内検証用の環境、クラウド上の構成も含める。
2. 2稼働中のサーバーの版・コンテナーイメージとワーカーの版を記録する。手元のPCに入ったパッケージや、取得済みイメージだけで判定しない。
3. 3利用者から管理APIまでを「外部入口→認証・プロキシ→GPUStack」の順に整理する。正規の入口を迂回できる直接ポートも確認する。
4. 4修正版か、暫定対策が実際に適用されているか、侵害点検が済んだかを別々に記録する。分からない項目は対象外にせず未確認とする。

管理者権限のある台帳・構成情報・稼働情報で点検し、攻撃用リクエストを送って確かめる必要はありません。使っている版が分かる画面や管理側の記録を残し、コンテナーを再作成する設定、起動元の定義、増設時のテンプレートとも照合します。

まずデータベースをバックアップし、復旧方法と停止時間を確認します。組み込みPostgreSQLを使うDocker構成では、公式手順はサーバーを停止してDBディレクトリーをバックアップする案内です。外部DBはその提供元の手順に従います。修正を含む安定版と既存構成の互換性を確認し、少なくとも2.2.0以降へ更新します。2.2.0を「現在の最新版」という意味では使っていません。

根拠はDocker更新、クラスタ更新、Helm更新です。Dockerの当該ページは2.0以降が対象で、古い系列は導入時の方法と版別の移行手順を確認してください。安定版と開発版・リリース候補版を混在させないよう公式資料が注意しています。

更新後は、サーバーと各ワーカーが意図した同じ版で起動していること、クラスタが正常であること、通常のログインと権限が保たれていることを確認します。機密データを含まない小さな推論で業務の接続を確認し、対応日時・実際の稼働版・担当者を残します。これは本記事の運用上の推奨であり、侵害がないことを証明するテストではありません。

公式勧告の暫定策は、ループバック通信にも認証を要求するforce_auth_localhost=true、外部通信をループバックとして信頼させないプロキシ／ゲートウェイ構成と外部入力ヘッダーの除去、VPNや入口側認証によるAPIの到達制限です。設定の適用方法は導入形態・版に合わせて確認し、記述しただけでなく実効状態を管理者が点検します。

ヘッダー除去だけでは同一ホストのプロキシ経路が残り得ます。VPNがあっても、その内側のすべての相手をGPUStack管理者として信頼してよいわけではありません。公開範囲の制限を急ぎつつ、修正版への更新を計画し、暫定策の期限と担当を決めてください。

ここからは公表された影響を踏まえた編集上の対応案です。侵害の疑いがある場合は、担当者がアクセスログ、管理設定の変更、APIキー発行、ワーカー・バックエンド登録など、取得可能な記録を保全します。調査前に一括削除して痕跡を失わないよう、隔離や復旧は組織の対応手順に従って進めます。

1. 1管理者アカウントとAPIキーを照合し、発行者・用途を説明できないものを調査する。疑わしいキーの失効は正規のサービスへの影響を確認して実施する。
2. 2カスタムバックエンド、モデル・ワーカーの追加や設定変更、ワーカーの不審な実行・外向き通信を調査する。
3. 3参照され得たワーカー認証情報やクラウド／プロバイダーの秘密情報を整理し、必要な失効・再発行を計画する。
4. 4侵害の程度に応じて、ワーカー等の隔離・信頼できる構成からの再構築を判断する。更新完了と調査完了の記録を分ける。

ログに異常が見つからないことだけでは、侵害なしとは断定できません。記録の有無・保存期間・確認できた範囲も残します。LLM利用者ができることは、管理担当者へ「GPUStackを使っているか、稼働版は何か、更新と侵害点検は別々に確認したか」を問い合わせることです。利用者自身で攻撃の再現を試す必要はありません。

LLMへ渡すのは、匿名化して利用を許可された台帳と公式資料に限ります。APIキー、トークン、クラウド認証情報、未加工ログ、個人情報を貼り付けないでください。ローカルモデルを使う場合も、入力の保存先や閲覧権限を確認します。

2026年11月10日11時台（JST）に、GPUStack公式勧告、v2.2.0リリース、CVEレコード、CISA公式GitHubデータ、GPUStackの更新ドキュメントを照合しました。公式ドキュメントのlatestは今後更新されるため、作業時には自分の導入版と対象版の手順を再確認してください。GPUStackの実機更新・攻撃再現・侵害調査は実施していません。新たな対象版や修正・侵害対応情報が公表された場合は本記事を更新します。