CISA KEVに登録されたGitLabのCVE-2026-85706について、Self-Managedの影響版と修正版、GitLab.comとの違い、ログ保全、更新経路、秘密情報への影響確認を公式情報で整理。開発者・情シス向けに、更新と調査を分けて進める実務チェックリストを案内します。
この記事の目次 9項目から選ぶ
何が起きたか：GitLabのファイル読み取りにつながる脆弱性
GitLabは2026年9月10日のセキュリティリリースで、CVE-2026-85706 を修正しました。条件によって、認証されていない利用者がGitLabサーバー上のファイルを読み取れる可能性がある脆弱性です。CISAは9月11日にKEVへ追加しています。
まず、自社の環境がSelf-Managedか、GitLab.com／Dedicatedかを分けてください。自社または委託先が運用する環境では、CE／EE、稼働版、公開範囲を確認し、修正条件と公式の更新経路を照合します。更新で弱点を修正する作業と、過去の不正アクセスを調べる作業は別です。
対象読者は開発基盤管理者、情シス、開発者、CSIRT等です。事実は2026年9月22日に確認した公開情報に基づき、以下の確認票・判断基準は編集部の防御運用例です。攻撃リクエストや再現手順は扱いません。
影響を受ける可能性がある環境：SaaSと自社管理を区別する
| 利用形態・担当者 | 最初に確認すること |
|---|---|
| Self-Managedの管理者 | CE／EE、GitLab本体の稼働版、全ノード・待機系、導入方式と更新責任者 |
| 保守委託している情シス | 委託先の対象環境、修正の証跡、ログ保全と影響調査の担当境界 |
| GitLab.com／Dedicatedの管理者 | 公式リリースでは修正済みと案内。自社運用の別インスタンスや連携基盤がないか確認 |
| 開発者・CI/CD担当 | 更新によるジョブ・リポジトリ操作への影響と、業務再開の確認項目 |
GitLab公式はGitLab.comが修正済みで、Dedicated利用者の追加対応は不要と案内しています。この記述を、同じアカウントで利用する別のSelf-Managed環境へ適用してはいけません。GitLab Runnerの版だけを見ても、GitLab本体の修正確認にはなりません。
影響バージョンと修正版
GitLab CE／EEについて、公式が示すCVE-2026-85706の範囲は次のとおりです。NVD APIの説明も同じ範囲を記載しています。
| 対象となる範囲 | 公表された修正リリース |
|---|---|
| 18.7以降、19.1.8未満 | 19.1.8 |
| 19.2以降、19.2.6未満 | 19.2.6 |
| 19.3以降、19.3.2未満 | 19.3.2 |
この表は当該CVEの修正条件であり、記載版が現在の推奨最新版だという意味ではありません。実際の更新先は、最新の保守対象とセキュリティリリースも確認して決めます。18.7より前の版がこの範囲に入らなくても、ほかの脆弱性やサポート期限まで安全と保証されるわけではありません。
古い版から更新する場合、表の修正版へ直接飛び越せるとは限りません。GitLabのUpgrade pathsで必須経由版を確認し、必要なバックグラウンド移行の完了を待って次へ進む計画を立てます。
なぜ重要か：非公開リポジトリやMFAだけでは対象外にならない
この脆弱性は未認証で成立し得る問題として公表されています。通常のログインにMFAを設定していても、それだけで修正版の適用を省略できません。また「リポジトリが非公開」という設定と「GitLabサーバーが対象版か」は別の判断軸です。
9月22日に取得したCISA KEV JSONでは、追加日は9月11日、期限欄は9月14日です。期限は米国の対象連邦機関向け指令の文脈であり、日本の全組織共通の法的期限ではありません。既知悪用の情報を、自社の公開範囲・保有情報・更新状況と合わせて優先度判断に使ってください。
KEV登録だけで、自社のコードやトークンが流出したとは断定できません。現時点で公開情報から確認できる範囲と、自社のログで確認できたことを分けて報告する必要があります。
まず確認すべきこと：初動チェックリスト
- 資産と担当：Self-Managedの全環境、CE／EE、版、導入方式、ノード構成、更新担当を記録する。
- 公開範囲：リバースプロキシ、アクセス制御、社内・委託先からの接続経路を既存設定で確認する。無許可の探索はしない。
- 証跡：プロキシ・アプリ・監査ログの保存期間、装置時刻、変更履歴、バックアップの保管先を確認する。
- 更新条件：修正対象版、公式の更新経路、必要な移行処理、復元条件と停止影響を確認する。
- 不審な操作：想定外のアクセス、管理者変更、トークンや連携先の利用を確認する。ログ不足なら「不明」とする。
GitLabの公式リリースには検知案内へのリンクもあります。調査担当が自社のログ形式と保存範囲を照合して利用し、本記事から攻撃を再現することはしません。
確認結果を現場で記録するには、GitLab Self-Managed脆弱性 初動対応チェックリストを使ってください。チェック状態だけをブラウザに保存し、機密情報は入力しない設計です。
推奨される初動対応：更新・保全・調査を並行する
1. 責任者を決め、必要な到達制限を判断する
対象版で外部公開されている、あるいは到達範囲が分からない場合は、通常の更新待ちにせず責任者へ共有します。アクセス制限や停止の必要性を業務影響と合わせて決め、暫定策、承認者、期限を記録します。制限を実施しても、修正済みとは扱いません。
2. 上書きされるログを保全する
更新や復旧操作の前に、可能な範囲でログと変更履歴を保全します。緊急の封じ込めを不必要に遅らせず、取得できなかった範囲も記録します。疑わしいログや秘密情報を、公開チケットや外部の解析サービスへそのまま貼り付けないでください。証拠保全の初動では、時系列と保管先の残し方を説明しています。
3. 更新経路と復元条件を確認して更新する
GitLabの更新前ガイドに従い、導入方式や複数ノード構成に合った計画を作ります。バックアップに加えて設定とsecretsの保全を確認し、復元時に必要な版の条件も確認します。バックアップは復旧のためのコピーであり、それだけで調査用の証跡が十分とは限りません。
CI/CDの停止や実行中ジョブの扱いを開発チームと調整し、必要な移行処理が終わったことを確認します。更新後は稼働版だけでなく、ログイン、リポジトリ操作、必要なCI/CD・連携・監視が動くことを確かめてください。
4. 秘密情報への影響を別に判断する
不正なファイルアクセスや認証情報の悪用が疑われる場合は、CSIRT等と影響範囲を調べます。秘密情報の値を報告へ貼らず、種類、権限、利用先、確認できた期間を整理してください。
失効・再発行・切替は調査結果と継続中の危険性を踏まえ、責任者が範囲と順序を決めます。更新だけで既に漏れた情報を無効化できるわけではありません。一方、根拠や依存関係を確認せず一斉に変更すると、業務停止や調査の混乱を招くことがあります。漏えい疑い初動テンプレートで事実と未確認事項を分けてください。
エスカレーションと完了の判断基準
| 確認した状態 | 対応・判断 |
|---|---|
| 対象版で公開中、制限や更新の見通しがない | 運用責任者へ即時共有し、緊急変更・制限・支援要請を判断する |
| 不審なアクセスや連携利用、必要なログの欠損 | CSIRT等へ共有し、調査範囲と秘密情報の扱いを判断する |
| 更新後に移行処理や重要なジョブが失敗 | 障害対応と並行し、切り戻しで戻る脆弱性も評価する |
| 修正・業務動作を確認したが調査が残る | 「パッチ対応完了／影響調査継続」と分けて報告する |
やってはいけないことは、本番での攻撃再現、ログ削除、必要な経由版を省いた更新、「検出なし」を「過去の侵害なし」へ読み替えることです。未確認・延期・失敗したノードには所有者と期限を残します。
関連用語・次に読むページ
- 対応票：GitLab専用チェックリスト、CVE初動対応。
- 基礎：KEV、パッチ管理、CVEとCVSSの違い。
- 学習：脆弱性管理のレッスン、用語クイズ。
- 完了確認：パッチ適用後の確認方法。
- 続きを探す：ニュース一覧、実務チェックリスト集。
公式情報・参考情報
確認日：2026年9月22日。修正条件と運用形態の説明はベンダー公式を優先しています。
- GitLab Critical Patch Release：19.3.2、19.2.6、19.1.8 — 9月10日公開。CVE-2026-85706の影響範囲、修正、運用形態、検知案内。
- CISA KEV JSON — 2026.09.21版。KEV追加日・期限の根拠。期限の適用範囲はCISA BOD 26-04を参照。
- NVD：CVE-2026-85706 — レコードはNVD公式APIで確認。
- GitLab：Plan your upgrade path — 必須経由版、移行処理、導入方式に応じた更新経路。
- GitLab：Before you upgrade — バックアップ・復元、設定・secrets、更新前後の機能確認。
