自己管理型GitLabを運用する組織は、CVE-2026-85706への更新と侵害確認を同じ作業として進める必要があります。
GitLabは2026年9月10日に修正版を公開し、米国サイバーセキュリティ・社会基盤安全保障庁（CISA）は翌11日、この脆弱性を実際の悪用が確認された既知悪用脆弱性カタログ（KEV）へ追加しました。
ただし、KEVへの追加は「対象となる全サーバーが侵害された」という意味ではありません。
インターネット公開の有無、稼働バージョン、更新前のログを確認し、組織ごとに影響を判断する必要があります。
CVE-2026-85706で確認された問題
GitLabの公式パッチ情報によると、CVE-2026-85706はリポジトリのコミットAPIにあるパストラバーサルの脆弱性です。
パスの制限と認証の実施が不十分だったため、一定の条件下では認証されていない利用者がGitLabサーバー上の任意ファイルを読み取れる可能性がありました。
GitLabは深刻度をCVSS 10.0と評価しています。
ファイル読み取りはデータの閲覧だけにとどまらず、設定ファイルに保存された認証情報や外部サービスへの接続情報が漏れた場合、別のシステムへの侵入につながるおそれがあります。
これは想定される影響であり、個々の環境で認証情報が実際に窃取されたと断定するものではありません。
影響を受けるバージョンと修正版
影響範囲はエディションとリリース系列ごとに確認します。
| 対象 | 影響を受ける範囲 | 修正版 |
|---|---|---|
| GitLab CE／EE 18.7から19.1系列 | 18.7以降、19.1.8未満 | 19.1.8以降 |
| GitLab CE／EE 19.2系列 | 19.2.6未満 | 19.2.6以降 |
| GitLab CE／EE 19.3系列 | 19.3.2未満 | 19.3.2以降 |
GitLabは、GitLab.comとGitLab Dedicatedについては修正済みであり、利用者側の対応は不要と説明しています。
一方、自社や委託先が管理するself-managed環境では、導入形態を問わずバージョン確認と更新が必要です。
カナダ・サイバーセキュリティセンターの勧告も、19.1.8、19.2.6、19.3.2より前の該当系列を挙げ、必要な更新を促しています。
実悪用の確認で対応が変わる理由
CISAは2026年9月11日、CVE-2026-85706をKEVへ追加しました。
KEVは、単に攻撃手法が理論上成立する脆弱性ではなく、実際の悪用を示す証拠に基づいてCISAが登録する一覧です。
そのため、管理者は更新の成否だけで対応を終えず、修正前に不審なアクセスがなかったかを調べる必要があります。
もっとも、公開情報だけでは、攻撃者、被害組織、侵害件数、読み取られたファイルの範囲までは確認できません。
根拠のない攻撃主体の推定や被害規模の断定は避け、各環境のログと資産情報を基準に判断します。
管理者が進める5つの対応
1. 自己管理型GitLabを漏れなく特定する
本番環境だけでなく、検証用、開発用、移行中の旧環境、委託先が管理する環境も資産台帳と照合します。
外部公開されていない環境でも、接続可能なネットワークと利用者を確認し、調査対象から機械的に除外しないことが安全です。
2. バージョンを確認して修正版以降へ更新する
該当系列を19.1.8、19.2.6、19.3.2以降へ更新し、更新後の実バージョンとサービス稼働状態を記録します。
複数ノード構成では一部のノードだけが古い状態で残らないよう、ロードバランサー配下を含めて確認します。
3. 更新前のログを保全して検知ルールを適用する
GitLabは公式パッチ情報に、CVE-2026-85706の悪用試行を調べる3件の検知ルールを追加しています。
その一つであるmetadata.pathを対象にしたGitLab公式の検知ルールは、自己管理環境のAPIログに残る不審なパス指定を確認するためのものです。
調査前にログを削除したり保持期間を短縮したりせず、時刻、送信元、対象経路、応答、関連する認証情報の利用記録を保全します。
4. 読み取りの兆候があれば認証情報の露出範囲を調べる
不審な読み取りが確認された場合は、対象ファイルに含まれ得たシークレット、データベース接続情報、外部ストレージやメールなどの接続情報を洗い出します。
そのうえで、インシデント対応責任者の管理下で必要な認証情報を失効、再発行し、更新前後の外部サービス利用履歴も確認します。
一律の再発行を急いで証拠や依存関係を失うより、優先順位と変更手順を決めて実施する方が復旧時の混乱を抑えられます。
5. CI/CDとリポジトリ周辺の整合性を確認する
GitLabはソースコードだけでなく、CI/CD変数、デプロイ権限、外部連携の起点にもなります。
侵害の兆候がある環境では、パイプライン定義、最近のジョブ実行、アクセストークン、Webhook、管理者権限の変更を時系列で確認します。
調査範囲は「脆弱なサーバーが直ったか」ではなく、「そのサーバーが接続していた先へ影響が広がっていないか」まで含めます。
組織として残すべき記録
対応記録には、対象インスタンス、確認したバージョン、修正日時、ログの保全場所、検知結果、認証情報の処置、判断した責任者を残します。
この記録があれば、後日新しい侵害指標が公開されたときにも同じ環境を短時間で再評価できます。
該当しなかった環境も、確認方法と根拠を記録しておけば、未確認と非該当を区別できます。
編集部の見解
今回の対応で評価したいのは、GitLabが修正版だけでなく、自己管理環境向けの検知ルールも公開した点です。
脆弱性対応はパッチ適用で閉じる作業ではなく、資産確認、証拠保全、侵害調査、認証情報の処置までを一つの手順にすると実効性が上がります。
平時に担当者と承認経路を決め、更新と調査を並行して開始できる運用へ改めることが、次の緊急対応を速くします。
よくある質問
GitLab.comの利用者も更新作業が必要ですか
GitLabはGitLab.comとGitLab Dedicatedを修正済みとしており、今回の公式案内では利用者側の更新は不要です。
自社または委託先が管理するself-managed環境は、別途バージョンを確認してください。
修正版へ更新すれば対応は完了ですか
更新は新たな悪用を防ぐために必要ですが、修正前のアクセスまで無かったことにはできません。
KEVへ追加された脆弱性として、更新前ログの保全と悪用試行の確認を併せて行います。
不審なログが見つかったら何を優先しますか
対象サーバーとログを保全し、読み取られた可能性のあるファイルと認証情報を特定してから、影響を受ける資格情報の失効と再発行を進めます。
社内で判断できない場合は、証拠を保持したままインシデント対応の専門家へ相談してください。
参考情報
- GitLab Critical Patch Release 19.3.2、19.2.6、19.1.8
- CISAによる既知悪用脆弱性カタログへの追加通知
- カナダ・サイバーセキュリティセンターのGitLab勧告 AV26-917
- GitLab公式のCVE-2026-85706検知ルール
- 株式会社greeden公式サイト
この記事に関連する株式会社greedenの取り組み
脆弱性対応は、更新後の影響確認や保守まで続く運用課題です。株式会社greedenは、Webシステム開発の要件定義からリリース後の保守・改善まで一気通貫で支援し、継続的な見直しに伴走します。