CVE-2026-85706: 重大なGitLabパストラバーサルの脆弱性、野外で悪用

GitLabは、未認証の攻撃者が脆弱なサーバーから任意のファイルを読み取ることを可能にする、Community Edition (CE)およびEnterprise Edition (EE)の重大な脆弱性に対する緊急セキュリティアップデートをリリースしました。CVE-2026-85706として追跡され、CVSSスケールで10.0と評価されたこの欠陥は、リポジトリコミットAPIに存在し、不適切なパス制御と認証の不履行の組み合わせにより発生します。

公開直後にリスクは急速に拡大しました。セキュリティ研究者は、GitLabがパッチをリリースした直後の2026年9月11日06:00 UTCにインターネット全体での調査を観測し始めました。その後、CISAは、攻撃が活発である証拠に基づいて、この脆弱性をKnown Exploited Vulnerabilitiesカタログに追加しました。

脆弱性の悪用が成功すると、GitLabサーバーに保存されている機密ファイルを曝露する可能性があります。これには、構成データ、クレデンシャル、シークレット、ログ、GitLabサービスがアクセス可能なその他の情報が含まれます。開発環境では、これらのファイルにCI/CDのシークレット、デプロイメントクレデンシャル、トークン、ソースコード関連のデータ、フォローオンコンプロマイズをサポートする情報が含まれている可能性があります。

この欠陥は、特にインターネットに接続されたセルフマネージドGitLabインストールにとって危険です。なぜなら、悪用にはアカウント、既存の特権、またはユーザーの操作を必要としないからです。watchTowrによれば、観察された攻撃パスの主要な前提条件は、GitLabインスタンスに少なくとも1つのパブリックプロジェクトが含まれていることです。

CVE-2026-85706の分析

この脆弱性は、GitLabのリポジトリコミットAPIにおけるパスのトラバーサルの問題です。GitLabは、影響を受けた機能に関するファイルパスの不十分な制約と認証の不履行を根本的な原因として説明しています。これにより、攻撃者が制御するパス情報が、GitLabがリポジトリファイルがあるべきと期待する場所を逃れ、アプリケーションが利用可能な他のファイルを参照することが可能になります。

GitLabが割り当てたCVSSベクターはCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:Nであり、これは低攻撃複雑性、認証不要、ユーザーの操作を必要としないリモートで悪用可能な脆弱性を反映しています。GitLabは、機密性と完全性に高い影響を与え、可用性はファイル読取りプリミティブ自体によって直接影響されないとしています。

CVE-2026-85706に関する最重要事項は、攻撃者がリモートで脆弱なリポジトリコミットAPIと対話でき、許可されたリポジトリディレクトリの範囲外のパスを要求できることです。GitLabがそのパスを正しく制約できない場合、サーバーはGitLabプロセスがアクセス可能な任意のファイルの内容を返す可能性があります。

watchTowrによれば、攻撃によりGitLab固有の構成ファイルやログファイルが曝露される可能性があり、それらにはクレデンシャル、シークレット、その他の機密情報が含まれています。システム構成やファイルパーミッションによっては、攻撃者がSSHキー、環境ファイル、データベースクレデンシャル、デプロイトークン、または他の機密アプリケーションデータをターゲットにすることもあります。

CVE-2026-85706は以下のGitLab CEおよびEEリリースに影響を与えます：

• すべてのバージョン18.7から19.1.8まで 18.7から19.1.8以前
• すべてのバージョン18.7から19.1.8まで 19.2から19.2.6以前
• すべてのバージョン18.7から19.1.8まで 19.3から19.3.2以前

GitLab.comは問題が公表される前にすでに修正バージョンを実行しており、GitLab Dedicatedの顧客はアクションを取る必要はありません。緊急修正の要件は、主にセルフマネージドGitLabインスタンスを運用している組織に適用されます。

少なくとも1つのパブリックプロジェクトが必要であるという要件は、意図的にオープンソースリポジトリ、公的開発プロジェクト、コミュニティリソース、またはその他の匿名アクセス可能なコンテンツを自社のGitLabインフラストラクチャにホストしている組織の露出を顕著に高めます。攻撃者は、エクスプロイトを試みる前にプロジェクトのメンバーシップや有効なGitLabアカウントを必要としません。

影響は単なる情報開示を超える可能性があります。GitLabはソフトウェア開発パイプラインの中心に位置し、ソースコード、CI/CD変数、デプロイクレデンシャル、インフラストラクチャ構成、アクセストークン、統合シークレットを含む非常に機密性の高い資料を保存しています。

攻撃者が任意のファイルアクセスを通じてそのようなクレデンシャルを取得した場合、初期のGitLab脆弱性はさらなる侵入活動の踏み台となる可能性があります。盗まれたシークレットは、ソースコードリポジトリ、CI/CDインフラストラクチャ、クラウドサービス、コンテナレジストリ、デプロイメントシステム、または他の接続されたリソースへのアクセスを提供する可能性があります。

これはまた、ソフトウェアサプライチェーンのリスクを導入します。開発クレデンシャルまたはビルドインフラストラクチャへのアクセスが可能になると、攻撃者は不正なリポジトリ変更を試みたり、ビルドプロセスを操作したり、専有コードを盗んだり、影響を受けるGitLab環境を通じて生成されたアーティファクトを信頼する下流システムを侵害したりすることができます。

GitLabはセキュリティ研究者 s3ntago が同社のHackerOneバグ報奨金プログラムを通じて脆弱性を報告したことを称賛しています。正確な私的発見および報告日は公に開示されていません。GitLabは修正バージョンを 2026年9月10日 にリリースし、クリティカルパッチリリースの一環として脆弱性を公に文書化しました。

公開から敵対的活動への移行は非常に迅速でした。WatchTowrは、Attacker Eye蜜桶ネットワークが 2026年9月11日06:00 UTC頃から脆弱性を狙った行動調査を検出し、外部のアクターがすでに脆弱性を逆解析し、インターネットにアクセス可能なGitLabシステムのテストを始めたことを示唆しています。

CISAは、2026年9月11日後に脆弱性をKEVカタログに追加し、攻撃が活発であることを確認しました。連邦行政部門のエージェンシーは、 2026年9月14日までに影響を受けたシステムを修正するよう指示され、CISAはまた、脆弱性をBinding Operational Directive 26-04の下で法医学的な精査が必要とされるものとしてマークしました。

公開されたCVE-2026-85706のPoCコードは公開直後に登場し、任意のファイル読取り動作を再現することに興味を持つ攻撃者にとって技術的障害をさらに低下させました。脆弱性の低い複雑性と認証されていない攻撃パスを合わせることで、公開による再現はより広範な機会主義的な悪用の可能性を高めます。

現在、信頼できる指標としての攻撃者のIPアドレス、ドメイン、マルウェアハッシュなどの、CVE-2026-85706に固有のキャンペーン全体を網羅するセテのIOCはありません。最も有用な指標は、脆弱なGitLab APIを狙ったリクエストの構造です。

WatchTowrは次のものに一致するパスに向けられたHTTP POSTリクエストを探すことをお勧めします：

/api/v4/projects/{id}/repository/commits/

それらのリクエストが疑わしいファイルパスパラメータを含むか、アクセスされたリポジトリに関連しないファイルを要求しているように見える場合、ディフェンダーは特に注意を払うべきです。

CVE-2026-85706の軽減策

GitLabは、影響を受けたすべてのセルフマネージドインスタレーションが修正バージョンのいずれかに直ちにアップグレードすることを強く推奨しています：

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

セキュリティ修正を含む後続のサポートされたリリースも脆弱性を修正するべきです。管理者は、実行中の正確なバージョンを確認し、自動更新が行われたと仮定しないようにすべきです。

直ちにパッチを当てることができない組織は、影響を受けたGitLabインスタンスへの不要なパブリックアクセスを削除するか、リバースプロキシ、ファイアウォール、ロードバランサー、またはネットワークレイヤーで接続性を制限する必要があります。これは一時的な露出削減の手段であり、GitLabの修正リリースのインストールの代わりにはなりません。

CVE-2026-85706の検出は、すべてのセルフマネージドGitLabインスタンス、その正確なバージョンを特定し、9月10日以降インターネットからアクセス可能であったかどうかを確認することから始めるべきです。1つ以上のパブリックプロジェクトをホストしているシステムは特に高い調査優先度を受けるべきです。

CVE-2026-85706の攻撃や偵察を検出するには、ディフェンダーはGitLab、リバースプロキシ、WAF、ウェブサーバートレメトリを次のためにレビューするべきです：

• HTTP POSTリクエストが/api/v4/projects/{id}/repository/commits/へのもの
• 不審なファイルパスパラメータを含むリクエスト
• 期待されるリポジトリディレクトリを越えるパストラバーサルシーケンス
• リポジトリAPIを通じてGitLab構成やログファイルを要求するリクエスト
• 以前に見られなかったソースからの大量のリポジトリコミットAPIリクエスト
• 匿名アクセスの後にサーバー側リソースを取得しようとする不審な試み
• クレデンシャル、構成ファイル、またはアプリケーションシークレットへの予想外のアクセス
• GitLabを通じて晒された可能性があるクレデンシャルを使用した新しい認証活動
• 不審なGitLab活動に続くCI/CD、クラウド、レジストリ、またはデプロイメントインフラストラクチャへの説明のつかないアクセス

watchTowrは具体的には、脆弱なエンドポイントに対する調査または攻撃の試みに直接的な証拠を提供できるため、リポジトリコミットAPIパターンのレビューを推奨しています。

パッチングにはレトロスペクティブな調査も組み合わせるべきです。CISAの法医学的な精査要件は、特に公開後すぐに攻撃が始まったことを考えると、組織が修正をデプロイする前に侵害されている可能性があることを反映しています。

疑わしいファイル読取りが確認された場合、管理者はどのファイルがアクセスされていた可能性があるかを正確に特定すべきです。潜在的に曝露されたファイルに含まれるシークレットは、そうでないことが証明されるまで侵害されたと考慮するべきです。

組織は以下のローテーションを検討すべきです：

• GitLabアクセスおよびパーソナルアクセストークン
• デプロイトークン
• CI/CD変数とシークレット
• データベースクレデンシャル
• SSHキー
• クラウドクレデンシャル
• コンテナレジストリクレデンシャル
• APIおよび統合トークン
• OAuthシークレット
• デプロイメントおよび自動化クレデンシャル

セキュリティチームは、それらのクレデンシャルを信頼していた下流システムも調査すべきです。GitLabの更新は任意のファイル読取りパスを閉じますが、攻撃者によって既に取得されたシークレットを無効化することはできません。

高リスクシステムの場合、ディフェンダーは既知の良好な記録と比較して、最近のリポジトリ、パイプライン、アカウント、ランナー、およびデプロイメント活動を調べ、潜在的なフォローオンの悪用を特定するべきです。予期しないパイプラインの変更、リポジトリの変更、新たに発行されたトークン、またはビルドインフラストラクチャへの異常なアクセスは調査の対象にすべきです。

CVSS 10.0の重篤度、確認された悪用、公に再現されたこと、および公開からスキャンへの急速な移行を考慮すると、セルフマネージドGitLabデプロイメントをインターネットに対面している場合に修正は緊急と見なされるべきです。