GitLab AI Gatewayの脆弱性、サンドボックスを突破してコマンド実行を可能に

GitLabは、研究者が任意のコマンド実行につながる経路を発見したことを受け、10点満点中9.9と評価されたGitLab AI Gatewayの脆弱性を修正した。この欠陥はセルフホスト型ゲートウェイに影響し、GitLab Duo Agent Platformにアクセスできる認証済みユーザーを必要とする。細工されたカスタムフローにより、プロンプトテンプレートのサンドボックスから脱出し、ゲートウェイプロセスの権限でコマンドを実行できる。

このインシデントは、すべてのGitLabデプロイメントに影響するリモートから悪用可能な欠陥よりも対象が限定的だ。GitLabホスト型ゲートウェイには同社がパッチを適用しており、それらのサービスを利用する顧客が自らゲートウェイを更新する必要はない。直ちに対応する責任を負うのは、セルフホスト型AI Gatewayを運用する組織である。

この違いが中心的な緊張関係を生む。セルフホスティングは、AI処理、インフラストラクチャ、データ経路に対する組織の管理を強化する。一方で、パッチ適用、監視、封じ込めの責任も顧客側へ移る。今回、信頼された環境内に配置されたコンポーネントが、コマンド実行の標的になった。

この脆弱性はCVE-2026-90970として追跡されている。GitLabは2026年10月2日、AI Gatewayバージョン19.2.4、19.3.2、19.4.1をリリースした。同社は影響を受ける運用者に直ちに更新するよう促したが、公開アドバイザリーでは回避策も、侵害検知に関する詳細なガイダンスも示していない。

GitLab AI Gatewayの脆弱性には直ちに更新が必要

緊急性の高い事実は単純だ。影響を受けるセルフホスト型ゲートウェイには、GitLabアプリケーションを更新するだけでなく、パッチ済みのAI Gatewayバージョンが必要である。

GitLabの重要パッチアドバイザリーでは、修正済みバージョンとして19.2.4、19.3.2、19.4.1の3つを特定している。該当するバージョン番号はAI Gatewayコンポーネントのものだ。接続されたGitLabインスタンスのバージョンと混同してはならない。

影響範囲はAI Gateway 18.1.6から始まる。19.2.4より前のバージョン、19.3.2より前の19.3系、19.4.1より前の19.4系が含まれる。古いサポート対象ブランチを運用している組織は、適切なパッチ済みリリースを選択する必要がある。

18.xおよび19.1系を使用している環境では、この表現にも注意が必要だ。GitLabは10月のアドバイザリーで、19.2.4未満の修正済みゲートウェイリリースを挙げていない。これらの系統の運用者は、古いブランチにとどまることが保護につながると考えるべきではない。

セルフホスト型AI Gatewayは、通常、コンテナまたはHelmデプロイメントを介して独立したサービスとして稼働する。GitLabのメインアプリケーションを更新しても、ゲートウェイイメージが置き換えられたことは自動的には証明されない。管理者はゲートウェイのデプロイメント自体を確認し、稼働中のイメージタグを検証しなければならない。

GitLabは、アドバイザリー公開前にセルフホスト型ゲートウェイの顧客へ連絡したとしている。また、修正はすでにGitLabホスト型ゲートウェイに適用済みだとも述べた。これにより、GitLab.com、GitLab Dedicated、およびGitLabホスト型ゲートウェイに接続するself-managedインスタンスは保護される。

この対象範囲により、資産の特定が最初の運用上の課題となる。セキュリティチームは、組織がGitLab Duoを利用していることを把握していても、どのゲートウェイモデルがそれを支えているかを知らない可能性がある。このサービスはGitLabが運用する場合もあれば、顧客環境内にデプロイされる場合もある。

チームは、デプロイメント記録、コンテナインベントリ、Helmリリース、GitLab Duo設定を通じて、その違いを検証すべきだ。GitLab製品名だけからゲートウェイの所有者を推測することは避けるべきである。self-managed GitLabインスタンスであっても、GitLabホスト型ゲートウェイを使用している場合がある。

CVEレコードでは、CVSS 3.1ベクター内で、この脆弱性に機密性、完全性、可用性の最大の影響を割り当てている。スコアが10ではなく9.9なのは、悪用に低い権限が必要なためだ。ユーザー操作は不要であり、脆弱なサービスはネットワーク経由で到達可能である。

低権限は匿名アクセスを意味しない。GitLabによれば、攻撃者は認証済みであり、Duo Agent Platformへのアクセスを持っている必要がある。この要件は初期攻撃者の範囲を狭めるが、侵害されたアカウントや、悪意ある内部者が含まれうる。

この欠陥は、初期アクセスの後にセキュリティ境界を越える。AIフローを扱う権限を持つユーザーが、ゲートウェイ上でオペレーティングシステムのコマンドを実行する権限まで継承すべきではない。この脆弱性は、アプリケーションレベルのアクセスを、より機微な実行環境の制御へと変えてしまう。

運用者は、この更新を独立した証跡を伴う独立した変更として扱うべきだ。GitLab向けの変更チケットが完了していても、AI Gatewayが安全であることは立証されない。正しい証跡は、稼働中のゲートウェイバージョンと、すべてのレプリカでロールアウトが検証されていることである。

この検証には、開発、ステージング、ディザスタリカバリ、一時的にスケールダウンされた環境を含めるべきだ。ネットワーク接続または認証情報を保持している、見落とされたゲートウェイインスタンスも依然として重要である。非アクティブなインターフェースは、サービスに到達できないことを保証しない。

カスタムフローがテンプレートデータを実行可能な動作へ変えた

中核となる失敗は、AIモデルが危険なコマンドを書いたことではない。テンプレート境界によって、細工されたデータが実行可能なアプリケーション動作へ到達できたことだ。

GitLabはこの問題を、カスタムフローのプロンプトテンプレートにおける不適切な無害化として説明している。カスタムフローは、Duo Agent Platform内の設定可能な複数ステップのAIワークフローである。YAML定義内で、プロンプト、コンポーネント、ルーティング判断、ツールを組み合わせることができる。

同社のカスタムフローのドキュメントは、これらの定義が単なるプロンプトテキスト以上のものである理由を示している。フローは作成、テスト、公開、プロジェクト向け有効化が可能で、GitLab上のアクティビティを通じて起動できる。エージェントを取り巻くアプリケーション設定として機能する。

脆弱な経路には、プロンプトテンプレートのサンドボックスが関与していた。サンドボックスは、テンプレートが安全でない属性や関数に到達するのを防ぐことを目的とした、制限付き実行環境である。CVE-2026-90970では、細工されたフロー設定がその制限を脱出できた。

公開されているGitLabの開示チケットでは、この問題をJinja2テンプレートのレンダリング中における安全でないメソッドアクセスに起因するものとしている。Jinja2は、テキストと変数、式を組み合わせるPythonテンプレートエンジンである。

チケットによると、会話履歴にはLangChainのHumanMessageオブジェクトが含まれていた。テンプレートはこのオブジェクトのパブリックなデシリアライズメソッドを呼び出すことができた。その後、安全でないシリアライズ済みペイロードによって、デシリアライズ中にPythonがオペレーティングシステムのコマンドを実行した。

デシリアライズとは、保存または送信されたデータをプログラムオブジェクトへ戻す処理を指す。選択した形式が、そのオブジェクトの再構築中にコードを呼び出せる場合、危険となる。Pythonのpickleデータは、信頼できないpickleコンテンツの読み込みが安全でないため、よく知られた例である。

報告された概念実証では、2段階のフローが使われた。最初のモデル対話で会話履歴が作成され、その後のテンプレート評価で履歴オブジェクトにアクセスし、危険なデシリアライズ経路が起動された。

この一連の流れにより、この問題は基本的なシェルインジェクションのバグとは異なるものになる。悪意ある値は、シェルへ渡される直接のコマンドパラメータとして現れる必要がなかった。代わりに、それぞれ単独では意味を持つ複数の機能が、実行チェーンを形成した。

フローは設定可能なプロンプトコンテンツを受け付けた。テンプレートエンジンはアプリケーションオブジェクトを受け取った。あるオブジェクトはデシリアライズメソッドを公開していた。受け入れられたシリアライズ形式はコードを呼び出すことができた。これらの条件が組み合わさり、意図されたサンドボックスを突破した。

モデル自体は信頼できるセキュリティ境界ではなかった。モデルは状態間でフローを進行させる助けとなったが、コマンドは決定論的なアプリケーション動作を通じて実行された。モデル出力だけをフィルタリングしても、脆弱なオブジェクトとテンプレートの関係には対処できない。

この違いは、組織がAIセキュリティ障害を分類する際に重要となる。プロンプトインジェクションは、命令を通じてモデルを操作しようとする試みを指す。CVE-2026-90970は、プロンプトテンプレートが侵入口となっているものの、モデルを取り巻くシステム内のソフトウェア脆弱性である。

したがって、従来のアプリケーションセキュリティの実践は依然として不可欠である。テンプレート入力には厳格な検証が必要であり、公開するオブジェクトのインターフェースは最小限にすべきであり、危険なデシリアライズ形式で攻撃者が制御するデータを処理すべきではない。サンドボックスも、内部で利用可能にする正確なオブジェクトに対してテストする必要がある。

報告されたコマンドは、Duo Workflow Serviceプロセスの権限で実行された。これにより、直ちに得られるオペレーティングシステム上の権限は、サービスアカウントの権限に限定される。ただし、ゲートウェイは機微な接続を扱い、信頼されたインフラストラクチャ内に存在するため、サービスレベルの実行は依然として重大である。

実際の影響はデプロイメントアーキテクチャに依存する。ネットワークが制限された最小権限のコンテナは、広範に接続されたサービスよりも、その後の侵害経路が少ない。いずれの構成でも、攻撃者は意図しないコード実行を取得できるため、パッチの必要性はなくならない。

このメカニズムは、深刻度がほぼ最大である理由を説明する。攻撃者は認証済みでDuoを利用できるアイデンティティから始めるが、結果として得られる実行はゲートウェイのセキュリティコンテキストへと越境する。このスコープの変化が、9.9という評価の中心にある。

セルフホスティングは制御とセキュリティ責任を同時に移す

このインシデントは、セルフホスト型AIインフラストラクチャに伴うトレードオフを浮き彫りにする。処理を近くに置くことは、ゲートウェイを顧客の運用上の信頼境界の内側に置くことでもある。

GitLabはAI Gatewayを、GitLab Duoの機能とAIモデルを接続するスタンドアロンサービスとして説明している。顧客はGitLabのマネージドゲートウェイを利用することも、GitLab Duo Self-Hostedで独自のゲートウェイを運用することもできる。

組織は、データ移動、モデルアクセス、ネットワーク経路、インフラストラクチャポリシーを制御するために、セルフホスティングを選ぶことが多い。これらの利点は、規制対象環境や厳格な内部統制を持つデプロイメントで重要になりうる。一方で、顧客自身がインベントリを管理し、保守すべき本番サービスがもう1つ増えることになる。

GitLab AI Gatewayの脆弱性は、この運用上の詳細を主要なセキュリティ課題へと変える。GitLabは、自社で管理するゲートウェイには直接修正を展開できた。セルフホスト型の顧客は、自らアップグレードを計画、実行、検証しなければならない。

このパターンは、データベース、IDサービス、CIランナーでよく見られる。違いは、AIゲートウェイが、かつてはより明確に分離されていたシステムを結び付ける点にある。ユーザー、ソースリポジトリ、エージェントワークフロー、モデルプロバイダー、場合によっては実行ツールの間に位置する。

そのため、侵害されたゲートウェイには、孤立したチャットボットインターフェースよりも大きな注意を払う必要がある。設定によっては、プロンプトコンテンツ、ワークフロー状態、サービス認証情報、プロバイダー接続、または社内開発活動に関するメタデータに接触する可能性がある。

ただし、これはCVE-2026-90970が接続されたすべてのシークレットを公開したことを意味するものではない。GitLabのアドバイザリーは、確認済みのデータ窃取や完全な侵害後の経路を報告していない。正しい結論は、任意のコマンド実行がさらなるアクセスへの現実的な経路を生み出すということだ。

チームは、ゲートウェイを特権的な統合サービスとして評価すべきである。そのプロセスアイデンティティ、マウントされたファイル、環境変数、ネットワーク経路、接続されたサービスアカウントが、影響範囲を決定する。これらの統制は、パッチ適用前の露出を再構築する際に重要となる。

コンテナ化は、その境界が意図的に設定されている場合にのみ役立ちます。コンテナは依然としてネットワークサービスに到達し、マウントされたシークレットを読み取り、外部へデータを送信できます。実効的なセキュリティは、ランタイムの権限と周囲のポリシーに左右されます。

GitLabのインストールガイドは、AI Gatewayコンテナからのアウトバウンドネットワークアクセスを制限することを推奨しています。エグレス制御は、侵害されたプロセスが接続できる宛先を限定します。コマンド実行の有用性を低下させることはできますが、ローカルへの影響をなくすものではありません。

ネットワークセグメンテーションは、もう一つの封じ込め層を提供します。ゲートウェイには定義済みのGitLabおよびモデルのエンドポイントへのアクセスが必要ですが、通常、内部ネットワーク全体への無制限な到達性は必要ありません。狭く絞った許可リストは、想定外のラテラルムーブメントを困難にします。

認証情報の設計も同様に重要です。長期間有効なシークレットを環境変数に直接保存すると、侵害後の魅力的な標的になります。短命な認証情報、分離されたサービスアカウント、狭く限定された権限により、サービス侵害後の被害を抑えられます。

セキュリティチームは、誰がカスタムフローを作成または変更できるかも検証すべきです。GitLabのドキュメントでは、複数のワークフローにおいてフロー管理操作をMaintainerやOwnerなどのロールに割り当てています。正確な露出範囲は、依然として製品構成と影響を受ける実装に依存します。

このアドバイザリは、普遍的に必須とされる単一のプロジェクトロールを挙げるのではなく、より広い表現で「Duo Agent Platform access」を用いています。管理者は、ドキュメントの例を決定的な悪用の前提条件に置き換えるべきではありません。実際の権限と、過去のフロー変更を確認すべきです。

セルフホスティングは依然として有効なアーキテクチャ上の選択肢です。教訓は、マネージドサービスが常により安全だということではありません。データ制御、ソフトウェア制御、インシデント対応の責任は一体となって伴う、ということです。

マネージドゲートウェイでは、信頼がベンダーの運用に集中します。セルフホスト型ゲートウェイでは、信頼が顧客側のパッチ適用、分離、監視に集中します。CVE-2026-90970は、修正の境界がホスティングの境界と正確に一致するため、この交換関係を明確に示しています。

企業の購買担当者にとって、セキュリティレビューは製品機能とデプロイメントの所有責任の両方を対象とすべきです。データがどこを移動するかという問いには、各コンポーネントを誰がパッチ適用するのかという問いを組み合わせる必要があります。運用上の所有責任を欠くアーキテクチャ図は不完全なままです。

パッチは脆弱性を閉じるが、検知の課題は残る

アップデートは既知の脆弱な経路を遮断しますが、公開アドバイザリは、過去の悪用が一度も起きなかったことを運用者がどう証明すべきかを示していません。

10月4日時点で、GitLabはCVE-2026-90970が実際に悪用されているとは公表していません。この事実は安心材料ではありますが、影響を受けるすべてのデプロイメントが手つかずだった証拠にはなりません。

公開された技術的な詳細は、迅速なパッチ適用の重要性を高めます。開示チケットには脆弱なオブジェクトの関係が記載され、ステージング環境でコマンド実行に成功したと報告されています。防御側と攻撃側の双方が、その資料を研究できます。

GitLabは、invisiblemeerkatとして知られるHackerOne研究者による責任ある開示を評価しています。責任ある報告により、GitLabは修正を準備し、影響を受ける顧客へ連絡する時間を得ました。しかし公開後もパッチ未適用のデプロイメントについて、その露出期間をなくすものではありませんでした。

認証要件は脅威ハンティングの方向性を形作るべきです。セキュリティチームは、Duo Agent PlatformのID、フロー管理イベント、カスタムフロー定義の変更から調査を始めるべきです。これらの記録を、脆弱だった期間のゲートウェイ活動と相関付ける必要があります。

異常なフロー構成は、特に会話履歴オブジェクトへアクセスしたりメソッドを呼び出したりするテンプレートでは、精査に値します。予期しないフローの作成、編集、公開、実行も追加の文脈を提供し得ます。一見通常に見えるフロー名によって、不審なテンプレートの挙動を見過ごすべきではありません。

ゲートウェイプロセスの活動も重要です。子プロセス、シェルの起動、予期しないバイナリ、異常なファイルアクセス、アウトバウンド接続は、コマンド実行を示す可能性があります。有用なデータは、すでに有効化されているコンテナ、ホスト、クラウドのテレメトリーに依存します。

コンテナの再起動により、ローカルの証拠は消去され得ます。そのため、現在実行中のコンテナだけを調べるよりも、集中ログとランタイムセキュリティテレメトリーのほうが有用です。侵害が疑われる場合、チームはインフラを置き換える前に利用可能なログを保全すべきです。

運用者は、ゲートウェイプロセスからアクセス可能なシークレットを確認すべきです。ローテーションの判断は、パニックではなく証拠と露出状況に基づく必要があります。ログがコマンド実行を示している場合、読み取り可能な認証情報にもアクセスされた可能性があるとみなしてください。

GitLabおよびモデルプロバイダーへのゲートウェイ接続には、別個の注意が必要です。コマンド実行を得た攻撃者は、トークンの再利用、設定の調査、接続先サービスへの到達を試みる可能性があります。公開記録は、そのような活動が発生したことを確認していません。

不審な証拠が存在する場合、パッチ適用を調査の終わりにすべきではありません。アップデートは既知のコードパスを取り除きますが、盗まれた認証情報を無効化したり、他所で加えられた変更を元に戻したりはしません。インシデント対応手順は引き続き必要です。

慎重さが求められる歴史的な理由もあります。セキュリティ報道では、同じ9.9の評価と同じCWE-1336の弱点カテゴリを持つ、2026年のより早期のAI Gateway問題CVE-2026-1868が特定されています。この脆弱性も、細工されたフローコンテンツとコード実行の可能性に関わっていました。

2件の重大なテンプレートエンジン問題は、すべてのカスタムフローが安全でないことを証明するものではありません。しかし、エージェントシステム内でテンプレート、アプリケーションオブジェクト、シリアライゼーションがどのように交わるかを、より厳密に見直す根拠にはなります。

この再発は、セキュリティテストが単独のコンポーネントだけでなく、その組み合わせを対象にする必要があることを示唆します。サンドボックスは文字列に対しては正しく動作しても、リッチなフレームワークオブジェクトがコンテキストに入ると失敗する可能性があります。ある層で安全なメソッドでも、テンプレートから呼び出せる場合には危険になり得ます。

エージェントプラットフォームは、多くの柔軟な仕組みを結び付けるため、この問題を強めます。プロンプト、ツール、履歴、ルーティングロジック、モデル応答、アプリケーションAPIは、繰り返される複数のステップにわたって相互作用します。あるステップで導入された状態が、後の段階で実行可能な入力になることがあります。

組織は、デプロイ前テストに敵対的なカスタムフローを追加すべきです。テストには、メソッドアクセス、オブジェクト探索、シリアライゼーション境界、複数ステップにわたる状態変化を含める必要があります。1回限りのプロンプトスキャンでは、報告された悪用チェーンを表現できません。

また、テンプレートをコードに隣接する成果物として扱うべきです。レビュー、所有責任、変更履歴、デプロイメント管理は、その潜在的な影響に見合うものにする必要があります。ファイルを「設定」と呼んでも、ランタイムの挙動を変える能力は低下しません。

GitLabは、悪用に必要なすべての条件を公には詳述していません。そのため、確信を持った露出評価には限界があります。チームは開示された前提条件を最低条件として利用し、明記されていない条件が安全性を保証すると考えるべきではありません。

対応が機能しているかを示す3つのシグナル

次の段階は、パッチの採用状況、実際の悪用の証拠、そしてGitLabによるカスタムフロー分離へのより深い取り組みに左右されます。

最初のシグナルは、19.2.4、19.3.2、19.4.1、またはそれ以降の修正版を実行しているセルフホスト型ゲートウェイの割合です。個々の組織は、すべての環境とレプリカにわたりこれを測定すべきです。これらのデプロイメントは顧客ネットワーク内に存在するため、業界全体の数値は入手できない可能性があります。

迅速な採用は、公開開示後に到達可能な攻撃対象領域を狭めます。採用が遅ければ、特にAIサービスが確立済みの脆弱性管理インベントリの対象外である場合に、リスクは長引きます。パッチダッシュボードでは、ゲートウェイの所有責任が見えるようになるべきです。

2つ目のシグナルは、悪用状況の変化です。GitLab、CISA、インシデント対応企業、影響を受けた顧客が、侵害指標や確認済みの事例を公表する可能性があります。能動的な悪用に関する報告があれば、優先順位は予防的なパッチ適用から、より広範なインシデント対応へ移ります。

防御側は、公開された概念実証と観測された攻撃を区別すべきです。技術的な再現は、文書化された条件下で脆弱性が機能することを示します。しかし、攻撃者が本番環境の顧客を侵害したことを立証するものではありません。

3つ目のシグナルは、AI Gatewayにおける構造的なセキュリティ変更です。狭い範囲のパッチは、開示されたメソッド呼び出しを遮断できます。より広い対応では、テンプレートに到達するオブジェクトを減らし、危険なシリアライゼーションを禁止し、カスタムフローの周辺にある分離を強化する可能性があります。

報告されたチェーンは機能の組み合わせから生じたため、この設計上の対応は重要です。1つのペイロードを防ぐことは有用ですが、安全でない能力の境界をなくすほうが、亜種に対するより強い保護になります。

GitLabの今後のリリースノートとコード変更により、どの層が修正を受けたのかが明確になるはずです。管理者は、フロー検証、監査イベント、検知クエリ、旧ゲートウェイブランチでサポートされるアップグレードパスに関する新しいガイダンスを確認すべきです。

エンタープライズ顧客は、このインシデントを利用して自らの運用モデルを今すぐ検証できます。重要な問いは、ソフトウェアインベントリにGitLabが存在するかだけではありません。AI Gatewayが、独立して所有され、パッチ適用され、ログ記録され、分離されたサービスとして存在するかどうかです。

フローを作成する開発者も、設定に与える信頼を見直すべきです。カスタムフローは、複数のステップにわたってツールとアプリケーションデータを連携させることができます。自動化スクリプトやCI定義と同じ懐疑的な姿勢で扱うべきです。

セキュリティレビュー担当者は、4つの境界をマッピングすべきです。すなわち、誰がフローを作成できるか、テンプレートがどのオブジェクトにアクセスできるか、フローがどのツールを呼び出せるか、そしてゲートウェイプロセスがどの権限を持つかです。複数の境界にまたがる弱点は、限定的なアクセスをインフラ制御へ変えてしまう可能性があります。

GitLab Duoを使用するナレッジワーカーは、このアドバイザリを理由に通常業務を放棄する必要はありません。ほとんどの利用者は、ゲートウェイの所有責任を自ら判断できません。組織のガイダンスに従い、独自のテストを試みるのではなく、予期しないフローの挙動を報告すべきです。

管理者には、より明確な行動が求められます。ホスティングモデルを特定し、実行中のゲートウェイバージョンを確認し、適切なパッチを展開し、不審な活動が見られる場合は証拠を保全してください。脆弱だった期間にわたるフロー変更とゲートウェイテレメトリーを確認しましょう。

パッチ適用後は、結果を永続的な運用記録に文書化してください。以前のバージョン、デプロイ時刻、影響を受けた環境、検証方法、脅威ハンティングの結果を記録します。その証拠は、将来の監査とインシデント再構築を支えます。

GitLab AI Gatewayの脆弱性は、AIアプリケーションロジックが従来の実行可能ソフトウェアへと変わる場所に関する警告です。障害はプロンプトテンプレートで始まり、フレームワークオブジェクトを通過し、オペレーティングシステムのコマンドで終わりました。

その経路は、「AI」というラベル自体以上に注意を向けるべきものです。モデルはワークフローに影響を及ぼせますが、信頼できない入力がコードになるかどうかを最終的に決めるのは、依然として通常のソフトウェア境界です。組織には両方の層を囲むコントロールが必要です。

組織でGitLab Duoを運用している場合、今日ひとつ具体的な問いを投げかけてください。これらのリクエストを処理するゲートウェイは誰が所有しているのか。答えが自チームであれば、そのバージョンをGitLabの修正版リリースと照合してください。次に、監視によって予期しないコマンド、変更されたフロー、アウトバウンド接続を検知できるかをテストしてください。パッチは開示されたGitLab AI Gatewayの脆弱性を閉じますが、持続的な安全性は、次のアドバイザリにも耐えるインベントリ、分離、証拠に依存します。