GitLab AI Gatewayの重大な修正で確認したい本体とは別の更新対象

GitLabはSelf-Hosted AI Gatewayの重大な脆弱性CVE-2026-90970を修正し、19.2.4、19.3.2、19.4.1を公開しています。公式説明では、Duo Agent Platformへアクセスできる認証済み利用者が、一定の条件下で細工したフロー設定を使い、プロンプトテンプレートのサンドボックスから抜け出してGateway上で任意コマンドを実行し得る問題です。

本記事は2026年10月18日に公式の修正告知と構成資料を確認した更新解説です。当日の新しい被害の速報ではありません。取得できた修正告知本文には公表日を明示する表示がなかったため、公表日フィールドを推測では埋めません。CVSS v3.1は9.9、Criticalですが、確認した資料から実際の悪用は判断できません。

出典：GitLab：AI Gatewayの重大なセキュリティ修正。

Self-ManagedとSelf-Hosted AI Gatewayは同義ではない

最初に確かめたいのは、自組織がどのGatewayへ接続しているかです。GitLabを自社運用しているから、必ずAI Gatewayも自社運用とは限りません。逆に、GitLab本体の更新台帳にAI Gatewayの更新が含まれていなければ、本体が新しくても別の確認が必要です。

公式告知は、GitLab.com、GitLab Dedicated、およびGitLab-hosted AI Gatewayを使うSelf-Managed環境について、修正が展開済みで利用者の対応は不要と説明しています。緊急更新の対象として案内されているのはSelf-Hosted AI Gatewayの設置環境です。製品名だけで全利用者へ同じ操作を指示しないでください。

本サイトが提案する構成票は、GitLab本体、AI Gateway、接続するモデルの三つを分けたものです。運用主体、URL、稼働版、更新担当をそれぞれ残します。別部署や委託先のサービスであっても、自社からどの経路へ接続しているかを確認するところから始めます。

関連する一次資料：GitLab：AI Gatewayのインストール手順。

問題はモデルの返答ではなくテンプレートを処理する場所にある

今回の公式説明に出てくるのは、カスタムフローのプロンプトテンプレートとそのサンドボックスです。言葉としての「プロンプト」が含まれていても、単にモデルへ悪い指示を送る話に縮めると、修正すべき場所を見誤ります。影響先として示されているのはAI Gateway上でのコマンド実行です。

一般論として、テンプレートを解釈する仕組みと、言語モデルが文章を生成する仕組みは異なります。前者で許される式や関数、実行環境の境界に問題があるなら、モデルを変更したり安全な回答を求める指示を増やしたりするだけでは、ソフトウェアの修正にはなりません。

公式告知は認証とDuo Agent Platformへのアクセスを前提として挙げています。したがって、インターネット上の誰でも無条件で攻撃できる問題として扱いません。一方、アカウントがある利用者だからすべて信頼できる、という判断も危険です。業務上の利用権限と、基盤でコードを実行する権限は分ける必要があります。

修正版の番号はGatewayの番号として照合する

公式の対象範囲は、18.1.6以降で19.2.4未満、19.3系列で19.3.2未満、19.4系列で19.4.1未満です。修正版は対応する19.2.4、19.3.2、19.4.1です。これをGitLab本体やモデルのバージョン欄と取り違えないようにしてください。

公式の導入資料を起点に、採用しているコンテナーやHelmなどの管理方法で実体を確認します。台帳には設定上のタグだけでなく、可能なら実際に稼働しているイメージの識別子も残すことを提案します。「latestを使っている」という宣言だけでは、いつ取得した何が動いているかを説明できません。

利用系列をまたぐ更新が必要な場合は、互換性や導入条件を確認します。単に三つの修正版のうち数字が大きいものへ切り替える手順にはしません。古い構成の移行経路が告知から判断できないときは、保守窓口へ確認する項目として明示します。

更新作業の前にフロー設定と権限を保全する

本サイトの運用案として、更新対象の設定、稼働イメージ、フロー変更履歴を記録してから作業します。必要なのは秘密の値を報告書へコピーすることではなく、どの設定がどの実行環境へ反映されていたかを後から説明できることです。モデル接続用の資格情報は、既存の安全な管理先で扱います。

カスタムフローを誰が作成・変更・適用できたかも確認します。管理画面の操作権限だけでなく、リポジトリ経由、API経由、自動化経由の変更があるなら、それぞれの承認と履歴を合わせます。フローをレビューする担当とGatewayの運用担当が違う場合は、同じ変更票で確認できるようにします。

侵害の疑いがある場合は、通常更新と別の対応が必要です。不審な設定や実行痕跡を消してから調べることを避け、組織のインシデント担当へ連絡します。なお、本記事は悪用を確認した報告ではなく、この調査経路は不審な事実がある場合の運用上の提案です。

複数レプリカと再起動後の状態まで確かめる

更新の実施結果は、設定ファイルを書き換えたことではなく、意図したイメージが稼働していることから確認します。冗長化しているなら、すべてのレプリカや待機側を対象にします。一部だけ古い状態が残ると、接続先や再起動のタイミングで結果が変わる可能性があります。

確認は通常の許可されたフローで行います。AI機能への要求、モデルからの応答、認証の失敗時の扱い、必要な監査記録をそれぞれ確かめます。利用者には、更新中に失敗した操作をむやみに繰り返さず、実行状況を確かめる窓口を案内すると、重複した処理や混乱を減らせます。

攻撃用のテンプレートを本番へ投入して修正を試す必要はありません。修正済み版の稼働確認と、業務の正常系・拒否されるべき操作の確認を分けます。セキュリティ検証を行うなら、環境、データ、実行権限を限定した計画として承認してください。

修正後もGatewayに置く権限は小さくする

以下は本CVEの修正内容とは別の、被害を限定するための設計案です。Gatewayの実行環境から到達できるモデル、ネットワーク、ファイル、資格情報を列挙し、不要な接点を減らします。AI連携に必要だからといって、開発者の個人用資格情報や本番の管理者鍵を同居させる必要はありません。

外部通信を制限する場合は、モデル提供元への正規の通信まで止めないよう、実際の依存関係から決めます。単純な一括遮断と緩すぎる全許可の間に、必要な宛先と監視を設計します。ログにも入力コードや秘密が無制限に残らないよう、収集する情報と保存期間を点検します。

また、フロー設定の変更はアプリケーションの実装変更に近い影響を持つことがあります。誰が変更し、何を確認して適用し、どの版へ戻せるかを残します。自動化が便利になっても、設定を渡す権限が基盤の実行境界に届くことを意識してください。

フローを変更できる人と基盤を運用する人の間を埋める

説明用に、開発チームがカスタムフローを管理し、基盤チームがGatewayを運用する場合を考えます。開発側ではテキスト設定の変更に見えても、基盤側では実行環境へ到達する入力です。両方の担当が、それぞれ相手の管理範囲だから安全だと仮定すると、確認すべき条件が抜け落ちます。

引き継ぎ資料には、どのリポジトリの設定を、誰の承認で、どのGatewayへ適用するかを残します。レビューでは用途、利用する機能、外部送信、実行権限の変化を見ます。モデルの指示文が丁寧かどうかだけを、設定の安全性の判定にしないでください。

設定の変更後に利用者の要求が失敗した場合は、権限を一括で広げて解決しない方針を勧めます。テンプレートの仕様、認証、モデル接続、ネットワークを順に切り分け、必要な最小範囲を修正します。エラー調査のためにトークンや入力コードをチャットへ貼り付ける運用も避けます。

また、ロールバック用の設定は、修正済みのGatewayで利用可能かを確認しておきます。古い設定と脆弱なイメージを一緒に戻すことを唯一の復旧策にしないためです。緊急時に停止するAI機能と、その間に使う通常の開発手順を用意すると、修正の適用を維持しやすくなります。

対応票に残す確認項目

以下は本サイトが提案する対応票の例です。すべてを同じ担当へ任せる必要はありませんが、対象環境と結果を対応付け、未完了の行には責任者と次の実施予定を残します。確認できなかった項目を、正常という結果で埋めないことが大切です。

確認箇所	残す内容	完了の判断
接続構成	GitLab本体とGatewayの運用主体	GitLab-hostedかSelf-Hostedかを確定
稼働実体	系列・タグ・イメージ識別子	各レプリカで意図した修正版が稼働
設定管理	フローの版と適用する担当者	どの承認で本番へ反映したかを説明
業務試験	通常フローと認証失敗時の結果	モデル接続と拒否の両方を確認
緊急停止	止める機能と代替の開発手順	旧い脆弱なイメージへ戻さず運用

今回の対応を二つの完了条件で閉じる

一つ目の完了条件は、対象のSelf-Hosted AI Gatewayが修正済み版で動き、必要な業務フローが使えることです。二つ目は、GatewayとGitLab本体の管理責任が分かれたまま更新漏れを起こさないことです。次回の告知を受け取る担当と更新対象一覧を対応付けます。

本体側の更新通知だけを監視していたなら、Gatewayの修正通知も追えるようにします。資格情報やフローの管理まで含めた変更履歴があれば、将来の問題でも「AIを使っていた」という曖昧な説明から、対象のソフトウェアと操作を具体的に絞れます。

今回の重要点は、AI機能の安全性をモデル選びだけで考えないことです。テンプレートを処理するサービス、そのサービスに渡す設定、実行場所の権限をそれぞれ管理し、提供元の修正を稼働環境まで届ける必要があります。