GitLab AI Gatewayの脆弱性により、認可済みDuoアクセスが重大なRCEリスクに
GitLabは、認可済みのDuo Agent Platformアクセスをセルフホスト型ゲートウェイ上でのコマンド実行へと転換し得る、CVSS 9.9のGitLab AI Gateway脆弱性を修正した。この欠陥はCVE-2026-90970として追跡されており、本来製品が強制すべき境界を越える。細工されたフロー設定により、プロンプトテンプレートのサンドボックスを脱出し、ゲートウェイ上で任意のコマンドを実行できる。
この条件は重要である。これはすべてのGitLabサーバーに対するゼロクリック侵害が報告されたという話ではなく、匿名のインターネット利用者に即時アクセスを与えるものでもない。悪用には認証とDuo Agent Platformへのアクセスが必要となる。しかし、GitLabの深刻度評価は、これらの条件が満たされた後に何が起きるかを示している。すなわち、低い複雑性でのネットワーク経由の悪用、追加のユーザー操作が不要であること、そして機密性・完全性・可用性にまたがる重大な結果が生じる可能性だ。
このインシデントは、統制と責任の間に直接的な緊張関係を生む。組織がAIインフラをセルフホストするのは、コード、プロンプト、モデルへのトラフィックを信頼できる境界内に維持するためである。しかしセルフホスティングは同時に、この機密性の高い素材を処理するサービスを更新する責任も組織に負わせる。GitLabホスト型ゲートウェイにはすでにパッチが適用されている一方、影響を受けるセルフホスト型ゲートウェイの運用者は自らアップグレードを完了しなければならない。
GitLab AI Gatewayの脆弱性が変えたこと
CVE-2026-90970は、AIワークフローを設定する権限を、オペレーティングシステムのコマンド実行へ至る潜在的な経路へと変える。
GitLabは2026年10月2日にこの問題を公開した。公開されている脆弱性記録によると、影響を受けるリリースには、18.1.6から19.2.4未満までのAI Gatewayバージョンが含まれる。19.3系は19.3.2未満で、19.4系は19.4.1未満で影響を受ける。
これらのバージョン境界は、GitLab本体アプリケーションのリリース履歴とは異なる。したがって管理者は、AI Gatewayイメージまたはデプロイメントそのものを確認すべきである。ゲートウェイが別個のデプロイメントライフサイクルに従う場合、画面に表示されるGitLabアプリケーションのバージョンだけを確認すると、誤った安心感につながりかねない。
修正版は19.2.4、19.3.2、19.4.1である。運用者は該当する修正版、またはそれより新しいサポート対象バージョンに移行すべきだ。GitLabホスト型ゲートウェイにはすでに修正が適用されているため、GitLab.comおよびGitLabのマネージドゲートウェイを利用する顧客は、同じパッチ適用作業に直面しない。
脆弱な経路は、特別に細工されたフロー設定から始まる。フローは、プロンプト、ツール、判断、アクションを組み合わせられるエージェント型のシーケンスを定義する。GitLab Duo Agent Platformは、単独で孤立したプロンプトに答えるのではなく、複数ステップのソフトウェア開発タスクを実行するためにこれらの設定を使用する。
プロンプトテンプレートは、フローの設定とランタイムデータを、AIモデルが処理できる指示へ変換する。テンプレートサンドボックスは、テンプレートの内容が安全でないアプリケーション機能やオペレーティングシステム機能に到達することを防ぐための制限環境である。CVE-2026-90970は、この境界内での不適切な無害化に関係している。
この弱点は、テンプレートエンジンで使用される特殊要素の不適切な無害化であるCWE-1336に分類される。実務的には、攻撃者が制御する構文が不活性なデータではなく、実行可能なテンプレート動作として解釈され得ることを意味する。正確な危険な結果は、周囲のアプリケーション、利用可能な機能、プロセス権限に依存する。
この欠陥についてGitLabは、その結果としてAI Gateway上で任意のコマンド実行が可能になるとしている。この結果は、AI応答を操作するよりも深刻である。脆弱性がモデル出力を越え、ゲートウェイをホストする従来型の実行環境に到達することを意味するからだ。
AI Gatewayと大規模言語モデルの違いは重要である。ゲートウェイは、GitLab機能とAIモデルの間に配置される独立したアプリケーションサービスだ。GitLabのゲートウェイ文書によると、このサービスはAIネイティブなGitLab Duo機能へのアクセスを提供する。モデルそのものとして機能するのではなく、モデルに関わるアプリケーションロジックとリクエストを処理する。
したがって、この脆弱性は、モデルが独自に脱出手段を見つけた、あるいは行動上の安全指示を無視したことの証拠ではない。報告された仕組みはテンプレート処理におけるソフトウェア脆弱性である。その入力が、たまたまエージェント型設定の入口を通じて到来する。
この事実により、インシデントはよく知られたセキュリティ分類に収まるが、その環境は重大性を高める。AIゲートウェイは、ソースコード由来のコンテキスト、ワークフロー指示、認証情報、モデルバックエンドへの接続を扱う場合がある。その接点でのコマンド実行の欠陥は、不正な形式のプロンプトや信頼できない回答以上のものを露出させ得る。
GitLabはCVE-2026-90970が広範に悪用されているとは公表していない。利用可能な記録も、攻撃者が本脆弱性を本番環境に対して使用したことを裏付けてはいない。特に公開により潜在的な攻撃者の標的が明確になった後、この検証上の空白を安全性の証明と解釈すべきではない。
したがって、直近に必要な変更は運用上のものである。これまで管理された内部コンポーネントと見なされていたセルフホスト型AI Gatewayは、緊急のバージョン確認、パッチ適用、アップグレード後のレビューを必要とする。そのリスクは、GitLabのメインインターフェースが公開されているかどうかだけからは判断できない。
認証済みのサンドボックス脱出が9.9評価を受ける理由
この脆弱性が重大なのは、攻撃の前提条件が攻撃者を制限する一方、サンドボックスが破られた場合の潜在的影響は広範だからである。
GitLabはCVE-2026-90970にCVSS 3.1基本スコア9.9を割り当てた。公開ベクトルはAV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hである。各要素は、認証済みの欠陥であっても深刻度スケールの最上位近くに位置し得る理由を説明している。
ネットワーク攻撃ベクトルは、潜在的な攻撃者がゲートウェイホストへのローカルシェルアクセスを必要としないことを意味する。関連サービスは、ネットワークからアクセス可能なアプリケーション機能を通じて悪意ある設定を受け取ることができる。ネットワークアクセス可能であることは、必ずしもインターネット全体に公開されていることを意味しないが、物理的またはローカルなアクセスを超えて攻撃経路を広げる。
低い攻撃複雑性は、悪用が限定的な競合状態や特殊なデプロイメント状態に依存しないことを示す。必要なのは無権限ではなく、低い権限である。ユーザーは認証済みであり、Duo Agent Platformへのアクセスを持っている必要がある。
ユーザー操作不要とは、設定が脆弱な経路に到達した後、別の人物がファイルを開いたり、ダイアログを承認したり、悪意あるリンクを訪れたりする必要がないことを意味する。この特性は、信頼された自動化が二度目の人間の操作なしに送信済み設定を処理することが多い共同開発環境で重要となる。
スコープ変更の要素は特に重要である。これは、悪用が元の脆弱なコンポーネントによって表されるセキュリティ権限を越えたリソースに影響を与え得ることを示す。ここではテンプレート入力は認可済みのエージェントワークフロー内で始まるが、ゲートウェイのコマンド実行環境へと越境できる。
最後の3つの指標は、機密性・完全性・可用性への高い潜在的影響を示す。コマンド実行は理論上、アクセス可能な情報の読み取り、ゲートウェイリソースの変更、サービスの妨害を可能にし得る。実際の被害は依然として、デプロイメントアーキテクチャ、プロセス権限、ネットワーク到達可能性、利用できる認証情報に左右される。
この文脈は、2つの誤解を防ぐ。「認証済み」という表現を、通常のアカウントレベルの問題として軽視するために使うべきではない。「リモートコード実行」という表現も、匿名の訪問者すべてが即座にGitLab環境を侵害できることを意味してはならない。
該当する攻撃者は、すでに有効なユーザーである可能性がある。侵害されたアカウント、盗まれたトークン、または過剰な権限を持つ自動化IDを支配する人物である可能性もある。正当なアクセスが無制限のインフラ権限と同義になることはほとんどないため、認証後もセキュリティ境界は機能し続けなければならない。
エージェントシステムは、この違いをより緊急のものにする。これらは構造化された指示を受け入れ、開発サービスをまたぐ一連のアクションを実行できる。フローを定義することを認可されたユーザーには広範なアプリケーション機能が必要な場合があるが、そのユーザーがフローを解釈するサービスのオペレーティングシステム権限を継承してはならない。
脆弱なサンドボックスは、この分離を維持するためのものだった。その失敗は、設定言語を実行可能な攻撃面へ変える。これがGitLab AI Gateway脆弱性における根本的な逆転である。エージェントの行動を統制するために設計された機能が、自らの封じ込め層を迂回する経路となる。
テンプレートインジェクションは、プロンプトインジェクションとも異なる。プロンプトインジェクションは、モデルに送られる指示を操作し、多くの場合、モデルの動作の誘導変更やコンテキストデータの開示を試みる。テンプレートインジェクションは、こうしたプロンプトを構築またはレンダリングするソフトウェアを標的とする。テンプレートエンジンが安全でないオブジェクトや関数を公開している場合、モデルがどう応答するかにかかわらず、結果にはサーバーサイド実行が含まれ得る。
CWE-1336はこの失敗の類型を形式化している。テンプレートエンジンの弱点は、ソフトウェアがテンプレートエンジンで実行可能な構文として扱われる要素を無害化できない場合に発生する。最も安全な対応は、モデルに別の行動指示を与えることではない。攻撃者が制御するデータが実行可能なテンプレート内容にならないようにするソフトウェア修正である。
この違いはインシデントレビューの形を決めるべきだ。チームはアプリケーション権限、設定履歴、ゲートウェイログ、コンテナ活動、下流の認証情報を調査する必要がある。AI会話のトランスクリプトだけを確認しても、ゲートウェイプロセスまたはその周辺ランタイムで発生する活動を見逃す。
ゲートウェイは、rootとして実行されていない場合であっても、一般に特権的な統合ポジションを占める。GitLabインスタンス、モデルサーバー、可観測性システム、内部ネットワークサービスと通信している可能性がある。運用者は、1つのコンテナ上でのコマンド実行が自動的にインフラ全体の侵害と等しいと想定するのではなく、これらの接続を把握すべきだ。
適切に設定されていればコンテナ化は影響を軽減できるが、インシデントを消し去るものではない。侵害されたコンテナは、マウントされたシークレット、サービストークン、ネットワークからアクセス可能なシステム、またはプロセスが処理するデータを依然として露出させ得る。過剰な権限、書き込み可能なマウント、広範なネットワーク経路は、この影響範囲を拡大する。
したがって、9.9というスコアは、すべての影響環境が最大の被害を受けた証拠ではなく、最悪ケースの標準化された評価を表す。管理者はこのスコアを実際のデプロイメントアーキテクチャと組み合わせて評価しなければならない。正しい結論は、緊急の調査と修正であり、自動的な侵害確認ではない。
セルフホスティングはデータ統制とパッチ責任を交換する
セルフホスト型ゲートウェイのセキュリティ上の約束は、顧客がそのゲートウェイを重要インフラとしてインベントリ化、分離、更新、監視できる場合にのみ有効である。
GitLabは、マネージド、ハイブリッド、完全セルフホスト型のAI構成をサポートしている。マネージド構成では、GitLabがゲートウェイを運用し、選定された外部モデルプロバイダーに接続する。セルフホスト型デプロイメントでは、ゲートウェイとモデル経路が顧客の管理するインフラ内に配置される。
このアーキテクチャは、厳格なプライバシー、データ所在地、ネットワーク分離の要件を満たすことができる。GitLabのセルフホスティングガイドによれば、組織はAIインフラを完全に制御するため、自らゲートウェイとモデルを運用できる。完全なセルフホスト構成は、一般的なインターネットアクセスが限定的、または存在しないネットワーク内でも運用可能である。
CVE-2026-90970は、その取り決めのもう一方の側面を示している。顧客は配置場所とデータフローを制御できる一方、展開したゲートウェイの保守も担う。GitLabは、顧客が管理する環境内で稼働するコンテナを密かに更新することはできない。
AIゲートウェイは、より一般的な開発インフラの隣に位置するため、この責任の所在は曖昧になり得る。プラットフォームチームがGitLabアプリケーションを管理し、機械学習チームがモデルサーバーを保守する場合がある。コンテナプラットフォームやネットワーク制御を別のグループが担当することもある。
どのチームもゲートウェイイメージを明示的に所有していなければ、そのパッチ適用状況はこうした境界の間で見落とされる可能性がある。マネージドゲートウェイでは、ベンダーがデプロイを管理するため、この特有の調整問題を回避できる。セルフホスティングでは、ゲートウェイを独立した本番サービスとして扱う内部プロセスが求められる。
最初の要点はインベントリである。組織は、GitLabのマネージドゲートウェイ、セルフホスト型ゲートウェイ、またはハイブリッド構成のいずれを利用しているかを把握する必要がある。ハイブリッド環境では、一部のリクエストは顧客側のインフラを利用し、別のリクエストはGitLab管理サービスを利用する可能性があるため、機能レベルで理解する必要がある。
二つ目の要点はバージョンの把握である。運用者は、概念実証システムや切断された環境を含め、すべてのセルフホスト型ゲートウェイインスタンスを特定すべきである。直接的なインターネットトラフィックを受信できない隔離済みデプロイであっても、認証済み内部者や侵害されたIDから攻撃を受ける可能性がある。
三つ目の要点はパッチ適用である。影響を受けるインストール環境には、表面上のGitLabアプリケーション更新だけでなく、修正済みのゲートウェイバージョンが必要となる。チームはデプロイの証跡を保持し、以前のイメージダイジェストを記録し、ワークロードが意図したバージョンで再起動したことを確認すべきである。
四つ目の要点は露出分析である。管理者は、脆弱な期間中にDuo Agent Platformへアクセスできたユーザーおよびサービスアカウントを特定すべきである。また、誰がフローを作成または変更できたのか、そしてそれらの操作が利用可能な監査記録を残しているかも判断する必要がある。
五つ目は実行時レビューである。パッチ適用後の調査では、ゲートウェイプロセスの挙動を通常時のベースラインと比較すべきである。予期しない子プロセス、コマンドインタープリタ、ファイル変更、新たな外向き接続、または異常なコンテナ再起動は調査に値する。
シークレットには特別な注意が必要である。GitLabのインストール文書では、ゲートウェイが署名付きJSON Web Tokensを用いてリクエストを認証すると説明されている。セルフホスト型サービスも、実行時環境を通じて設定値と鍵を受け取る。これらの仕組みは通常運用に必要だが、侵害されたプロセスがアクセスできる認証情報はローテーションが必要になる場合がある。
インストールガイダンスでは、AI GatewayとDuo Agent Platformを、別々の署名鍵ペアを持つ別個のサービスとしても説明している。この分離は、防御側に有用なレビューの枠組みを与える。両サービス、その信頼関係、および両者の間で使用される認証情報を評価すべきである。
ネットワーク設計は、影響を大きく変え得る。モデルサーバーと限定的に定義されたGitLabエンドポイントにしか到達できないゲートウェイは、内部ネットワーク全体に広範なアクセスを持つゲートウェイよりも攻撃機会が小さい。送信制限、ワークロードID、読み取り専用ファイルシステム、最小限のコンテナ権限はいずれも有意義な制御であり続ける。
ただし、ネットワーク分離はパッチ適用の代替ではなく補完として用いるべきである。脆弱な内部サービスは、別の侵害された内部アカウントまたはワークロードから攻撃され得る。セグメンテーションは横方向の移動とデータアクセスを制限するが、安全でないテンプレート処理を修復するものではない。
運用者は、ゲートウェイを通過するデータについても検討すべきである。セルフホスティングは、プロンプトに独自のソースコード、Issueのコンテキスト、社内指示が含まれ得ることを理由に選ばれる場合が多い。侵害が発生していた場合、調査担当者は、コンテナ内にどのファイルが存在したかだけでなく、ゲートウェイがどの情報にアクセスできたかを判断する必要がある。
この作業は、CIランナー、アーティファクトリポジトリ、シークレットマネージャーの保護と同じ運用上のカテゴリーに属する。これらのサービスはいずれも、開発者が制御する入力を自動化されたアクションに変換する。その有用性は特権的な接続性に由来し、それゆえ分離と更新頻度が重要になる。
ここから得るべき教訓は、マネージドAIインフラが常により安全だということではない。マネージドサービスではベンダー側に責任が集中し、顧客のパッチ作業は減るが、顧客は異なる信頼、データ所在地、依存関係のトレードオフを受け入れる。教訓は、重大なゲートウェイの欠陥が現れた際に誰が対応すべきかを、セルフホスティングが変えるという点にある。
以前の9.9の脆弱性は、これが単発のパッチ対応ではないことを示す
CVE-2026-90970は、2026年に公文書化されたGitLab AI Gatewayのテンプレート問題として、深刻度9.9と評価された2件目の脆弱性であり、アーキテクチャレビューの必要性を強めている。
2026年2月、GitLabはAI GatewayのDuo Workflow ServiceコンポーネントにおけるCVE-2026-1868に対処した。GitLabの公開CVE割り当てでは、細工されたDuo Agent Platformフロー定義を通じた、ユーザー提供データの安全でないテンプレート展開について説明している。
以前の脆弱性は、同じCVSS 3.1ベクターと9.9の深刻度スコアを持っていた。修正版リリースにはAI Gatewayバージョン18.6.2、18.7.1、18.8.1が含まれた。GitLabはこの脆弱性の発見者として社内チームメンバーをクレジットしている。
現在の記録によれば、新たな脆弱性はバージョン18.1.6以降のリリースラインに影響し、19.4系列まで及ぶ。両問題の公開説明には、細工されたフロー定義または設定、テンプレート処理、低権限の認証済みアクセス、そしてコマンド実行の可能性が含まれている。
この類似性は、パッチが同じ形で失敗したことを証明するものではない。公開されている脆弱性の要約は、CVE-2026-90970が回帰、不完全な以前の修正、または別個の安全でないテンプレート経路のいずれであるかを確定するには限定的すぎる。これらの可能性を確認済みとして扱うことは、証拠を過大評価することになる。
それでも、防御側は10月の開示を孤立した事象として評価すべきではない。同じ広範な信頼境界の周辺で重大な発見が2件生じたことは、フロー設定処理がより深いテストに値することを示している。1行のバージョンアップグレードで開示済みの経路を閉じられても、より広い設計上の疑問は残り得る。
この事例における主な対立軸は、プラットフォームのガバナンス上の約束と、実行可能な設定面の現実との間にある。GitLabは、エージェント型フローを、確立済みの開発プロセス内で動作する管理された自動化として位置付けている。認可されたフロー作成者がゲートウェイレベルのコマンドへ越境できるなら、そうした制御の価値は失われる。
この問題はGitLabの製品カテゴリに固有のものではない。AIゲートウェイ、エージェントオーケストレーター、ワークフローエンジンはいずれも、柔軟なユーザー入力を特権的な操作に変換する。製品インターフェースが宣言的なファイルとして提示していても、その設定形式はプログラミング言語になり得る。
この柔軟性は、繰り返し生じるセキュリティ上のトレードオフをもたらす。顧客は、リポジトリを調査し、ツールを呼び出し、イベントに応答し、複数ステップの目標を完了できるカスタマイズ可能なエージェントを求める。新たなツール、式、テンプレート変数、プラグインが加わるたび、オーケストレーション層が安全に解釈すべき範囲は拡大する。
厳格な設定言語はリスクを抑えられるが、顧客によるカスタマイズを制限する。柔軟な言語はより多くのワークフローを支えるが、成熟したサンドボックス、パーサー制御、権限境界、セキュリティテストを必要とする。単一のプロセスが信頼できないテンプレートをレンダリングし、かつ価値の高いインフラへのアクセスを持つ場合、リスクは上昇する。
したがって、防御には複数の独立した層が必要である。パーサーは信頼できない値をデータとして扱うべきである。テンプレート環境は、可能な限り小さいオブジェクトセットのみを公開すべきである。認可は、フローを送信できる人物を制限すべきである。ゲートウェイの実行環境は、最小限のファイルシステム、ネットワーク、認証情報アクセスにとどめるべきである。
監査可能性も別の層を提供する。フローの作成および変更イベントは、特定の人間またはサービスIDに帰属可能であるべきだ。組織は、送信された設定と、その後のゲートウェイ活動を結び付けられる必要がある。この連鎖がなければ、侵害の確認または除外ははるかに難しくなる。
以前の脆弱性は、チームがアップグレード検証を扱う方法も変える。最新の修正済みイメージが正常に起動したことを確認するだけでは不十分である。運用者は、古いレプリカ、キャッシュされたイメージ、テストクラスター、災害復旧環境が影響を受けるバージョンを保持していないことを確認すべきである。
切断された環境は、特に誤解を招きやすい。一般的なインターネットアクセスがないことで一部の外部脅威は軽減されるが、セキュリティ通知やパッチの提供は遅くなり得る。その環境内の認可済みユーザーは、脆弱性に必要なアプリケーション機能へ到達できる可能性が依然としてある。
懐疑的な評価では、依然として不明な点も認めなければならない。公開記録は、まだ概念実証、詳細な呼び出し経路、または侵害が確認されたテレメトリを提供していない。また、すべてのデプロイに共通する侵害後の指標も特定していない。
こうした欠落は、観測された攻撃について確信を持った主張をすることを制限するが、パッチ適用の推奨を弱めるものではない。ベンダーが確認した、スコア9.9のコマンド実行脆弱性は、即時の対処を正当化する十分なリスクをもたらす。公開された悪用の証拠を待つことは、不確実性と引き換えに防止可能な露出を受け入れることになる。
より強い長期的な問いは、テンプレート処理が現在の信頼コンテキストで必要なままであるかという点だ。GitLabは、顧客がパッチを適用する時間を確保した後に、より技術的な詳細を公開することで将来のリスクを低減できる。根本原因に関する情報は、どの境界が失敗し、どの補完的制御が最も重要かを運用者が理解する助けとなる。
一方、顧客はカスタムエージェントフローをコードとして扱うべきである。CI設定と同等のレビュー、所有権、変更管理、テストに値する。プラットフォームがその内容をアクションに変換する場合、視覚的または宣言的なインターフェースであっても、ワークフローが実行不可能になるわけではない。
防御側が次に注視すべきこと
次の評価は、パッチの導入状況、GitLabによる根本原因の開示、実際の悪用に関する証拠という3つのシグナルに依存すべきである。
最初のシグナルは、セルフホスト型の運用者が修正済みAI Gatewayバージョンに迅速に到達するかどうかである。GitLabはホスト型サービスを制御しているが、プライベートインフラ内のすべての顧客デプロイを把握することはできない。セキュリティチームは、通常のソフトウェア更新レポートにゲートウェイが含まれていると想定するのではなく、自ら完了の証拠を確立すべきである。
その証拠では、デプロイ、以前のバージョン、置き換えイメージ、再起動時刻、検証結果を特定すべきである。開発環境および災害復旧システムも対象とする必要がある。組織がこのインベントリの作成に苦労するなら、このインシデントは脆弱性自体を超えた所有権の問題を明らかにしている。
迅速なパッチ導入は、企業がセルフホスト型AIコンポーネントを従来の本番インフラとして管理できるという見方を強める。導入が遅い、あるいは測定されない場合、プライベートデプロイを支える制御上の論拠は弱まる。重要なミドルウェアが追跡されていなければ、データのローカリティが提供する保護は限定的である。
二つ目のシグナルは、GitLabによるより完全な技術的説明である。防御側は、CVE-2026-90970が新たなテンプレート経路、回帰、または以前の脆弱性に対する不完全な緩和策のいずれを表すのかを知る必要がある。この区別は、周辺アーキテクチャおよびテスト戦略に対する信頼性に影響する。
有用な開示では、不要な悪用の詳細を示すことなく、脆弱なコンポーネント、影響を受ける権限境界、封じ込めに向けた変更点を説明すべきです。また、個別の Agent Platform と AI Gateway サービスで、インシデント後に異なる対応が必要かどうかも明確にする必要があります。
異なる根本原因が確認されれば、幅広いテンプレートの強化が複数の発見を通じて機能していることが示唆されます。以前の緩和策を迂回する証拠が見つかれば、当初のセキュリティ境界が包括的に設計されていたのか、より厳しい疑問が生じます。
3つ目のシグナルは、悪用に関する信頼できる証拠です。GitLab やセキュリティ機関については、侵害の痕跡、既知の悪用済み脆弱性リスト、改訂された対応ガイダンスを注視すべきです。検証可能なテレメトリーを含む独立したインシデント報告も重要になります。
そのような証拠が現れるまでは、CVE-2026-90970 が実際に悪用されていると記事で表現すべきではありません。公的な確認がないことは、悪用が発生していないことの確認と同義ではありません。組織は見出しだけでなく、露出状況と影響に基づいて対応を判断する必要があります。
チームは、4つの実務的な問いから始められます。セルフホスト型の AI Gateway を運用しているか。すべてのインスタンスは 19.2.4、19.3.2、19.4.1、またはそれ以降を実行しているか。影響を受けた期間中に、誰が Duo agent フローを変更できたか。ゲートウェイの処理は、どのシステムやシークレットに到達できるか。
回答は、インシデント記録、設定履歴、関連ログとともに保存すべきです。デプロイメントノート、責任者に関する判断、レビュー証拠を結び付ける必要があるチームは、検索可能なナレッジベースを維持できます。ドキュメント化そのものが脆弱性を修正するわけではありませんが、証拠が分断されていると、封じ込めやその後の監査が遅れるおそれがあります。
GitLab AI Gateway の脆弱性は最終的に、agent インフラが CI システムやその他のコード実行サービスと同等の運用規律を受けているかを問うものです。影響を受けるゲートウェイにパッチを適用し、実行中のイメージを検証し、許可されたフロー変更を確認し、証拠により必要と判断される場合は露出した認証情報をローテーションし、ゲートウェイの権限を縮小してください。
そのうえで、より難しい問いを投げかけるべきです。来月、別の agent 設定が信頼境界をまたいだ場合、インシデント中にインベントリを作り直すことなく、チームは所有者、影響を受けるバージョン、到達可能な資産、対応経路を特定できるでしょうか。
