開発プラットフォーム「GitLab」で、複数の脆弱性が修正された。GitLabは2026年8月26日、Community Edition（CE）およびEnterprise Edition（EE）向けにバージョン19.3.1、19.2.5、19.1.7を公開し、セキュリティ修正7件を含む更新を提供した。最も深刻度が高いと評価されたのは、AIアシスタント機能「GitLab Duo」のClaude AIエージェントに関する脆弱性で、CI（継続的インテグレーション）環境で任意のコマンドを実行できた可能性があるとされる。JPCERT/CCも「Weekly Report 2026-09-02号」で本件を取り上げ、修正済みバージョンへの更新を呼びかけている。
最上位の「High」はAIエージェントの設定読み込みに起因
今回の更新で修正された7件のうち、最も深刻度が高いのはCVE-2026-18252（重要度「High」、共通脆弱性評価システムCVSS 3.1の基本値7.3／10点満点）である。GitLabの発表によると、Claudeエージェントがユーザーの制御下にあるソースから設定を読み込んでいたため、特定の条件下で、developerロールの権限を持つ認証済みユーザーがCIコンテキストで任意のコマンドを実行できた可能性がある。影響を受けるのはEEのみで、18.9以降の全バージョン（19.1.7、19.2.5、19.3.1より前）が対象となる。この脆弱性はHackerOneのバグバウンティプログラムを通じて外部の研究者から報告された。
CIパイプラインは、リポジトリのコードをビルド・テスト・デプロイするための実行環境であり、多くの場合デプロイ先の資格情報やクラウドAPIのトークンを扱う。そこで任意のコマンドが実行できるということは、権限の低い一開発者アカウントが、本来触れられない範囲まで手を伸ばせる余地があったことを意味する。
残る6件はDoSと認可不備 「Critical」はゼロ
残りの6件は、重要度「Medium」が5件、「Low」が1件で、「Critical」に分類されたものはない。内容はサービス運用妨害（DoS）と権限・認可の不備に大別される。
- CVE-2026-77801（Medium、CVSS 6.5）：インポートパイプラインにオブジェクト数の上限が設定されておらず、認証済みユーザーがバックグラウンドジョブ処理に影響するDoSを引き起こせた可能性がある。CE／EEの12.8以降が対象
- CVE-2025-10903（Medium、CVSS 6.5）：SCIM（利用者アカウントを外部のID管理システムと自動連携するための規格）によるユーザープロビジョニング機能で、細工された入力によって無制限のループが発生し、DoSにつながる可能性がある。EEの11.10以降が対象
- CVE-2026-3035（Medium、CVSS 5.5）：認可チェックの不備により、プロジェクトのMaintainer権限を持つユーザーが、利用を許可されていない保護環境のターミナルにアクセスできた可能性がある。EEの11.3以降が対象
- CVE-2026-4398（Medium、CVSS 5.4）：ネームスペースの検証が欠けていたため、自己管理型インスタンスにおいて、認証済みユーザーがアクセス権のないネームスペースのコンプライアンスフレームワークを自身のプロジェクトに割り当てることができた可能性がある。EEの18.3以降が対象
- CVE-2026-15387（Medium、CVSS 4.3）：ジョブの依存関係の処理が不適切だったため、developerロールの権限を持つユーザーがPipeline Execution Policy適用ジョブの実行環境に影響を与えられた可能性がある。EEの19.1以降が対象
- CVE-2026-7487（Low、CVSS 3.5）：認可チェックの不備により、マージリクエストを作成したreporterロールのユーザーが、マージリクエストの承認ルールをリセットできた可能性がある。EEの13.1以降が対象
GitLabの発表時点で、これらの脆弱性が実際に悪用されたとの記述はない。なお同社は、セキュリティ修正の詳細を記した課題（issue）を、修正リリースから90日後に公開する方針を取っている。
SaaS版は対応不要、自己管理型はダウンタイムの計画を
クラウドサービスとして提供されるGitLab.comはすでにパッチ適用済みで、GitLab Dedicatedの利用者も対応は不要とされている。一方、自社で運用する自己管理型（self-managed）のインストールについては、GitLabが「可能な限り速やかに」最新バージョンへアップグレードするよう強く推奨している。
注意が必要なのは、今回のパッチにデータベースマイグレーションが含まれる点だ。GitLabによると、単一ノード構成ではマイグレーションの完了までGitLabが起動できないため、アップグレード中にダウンタイムが発生する。複数ノード構成の場合は、同社が案内するゼロダウンタイムアップグレードの手順に従えばダウンタイムなしで適用できるとしている。業務時間中の無停止更新を前提にしていると想定外の停止につながりかねないため、構成に応じた作業計画を先に決めておきたい。
GitLabの定期パッチリリースは毎月第2・第4水曜日に提供され、深刻度の高い脆弱性には随時の緊急パッチが出される。今回の8月26日は第4水曜日にあたり、定期リリースの枠内での提供である。
AI機能の追加は、そのまま攻撃面の追加でもある
今回の7件で目を引くのは、最も深刻度の高い脆弱性が、従来型のWebアプリの不備ではなく、開発支援AIエージェントの設定読み込みに起因していた点だ。エージェントが「どこから指示を受け取るか」の境界が曖昧なままユーザー制御下の入力を信頼してしまうと、開発者権限の一アカウントがCI環境でのコマンド実行にまで到達しうる。AIエージェントを製品に組み込む動きが広がるなかで、設定やプロンプトの供給元をどこまで信頼するかという設計判断が、そのまま権限昇格の経路になり得ることを示す例といえる。
同時に、実務面での教訓はより地味なところにある。CI/CDプラットフォームは組織のソースコードとデプロイ権限が集中する場所であり、いったん侵害されれば影響がサプライチェーン全体へ波及するリスクがある。にもかかわらず、業務停止を伴うアップグレードは後回しにされやすい。DBマイグレーションを含むパッチが出た時点で、構成に応じたダウンタイムの見積もりと作業枠の確保まで一気に決めてしまうこと、そしてdeveloperやMaintainerといった中間的な権限を「安全側」と見なさず棚卸しの対象に含めること——地味だが、この二つを習慣にできるかどうかで差がつく。今回修正された脆弱性の多くが、匿名の攻撃者ではなく「認証済みの内部ユーザー」を起点としている点は、権限設計を見直す実務的な理由になる。
同じ手口に、自社は備えられていますか？