GitLabの「満点10.0」は塞がれた。読み取られた秘密情報はそのままだ

GitLabは9月10日、リポジトリのcommits APIに存在するパストラバーサルの脆弱性CVE-2026-85706を修正するクリティカルパッチリリースを公開した。CVSSスコアは10.0。CISAは翌日、実際の悪用の証拠があるとしてこれをKnown Exploited Vulnerabilities（既知の悪用された脆弱性）カタログに追加し、連邦政府の文民機関に3日間という修正期限を課した。同庁が発行する期限としては最短の部類である。その期限はすでに過ぎた。セキュリティ企業watchTowrは、9月11日の時点で実環境における探索行為を観測したと報告している。

個々の日付よりも、この順序が重要だ。ベンダーのパッチと、攻撃者がすでに悪用している脆弱性だけが載る政府カタログへの登録との間隔は、わずか1日だった。自前のインフラでGitLabを運用している組織にとって、修正が公開されてから実際に適用されるまでの空白は、そのサーバーが「要求した者なら誰にでも読める」状態にあった時間そのものである。

何が起きたのか

GitLabのアドバイザリは、この問題をこう説明している。

GitLabは、特定の条件下において、リポジトリのcommits APIにおける不適切なパス制限と認証強制の欠如により、未認証のユーザーがGitLabサーバー上の任意のファイルを読み取れた可能性のある問題を修正しました。

CVSSベクターは CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N である。ネットワーク経由で到達可能、攻撃の複雑さは低、必要な権限なし、ユーザー操作不要。そして満点に押し上げている要素が、スコープの変更（Scope: Changed）だ。スコープ変更とは、被害範囲が脆弱なソフトウェアの内側で止まらないというスコアリング体系なりの表現である。今回それは正しい評価であり、本稿の残りはその理由についての議論だ。

この問題はGitLabのHackerOneプログラムを通じて報告され、研究者はs3ntagoとしてクレジットされている。GitLab.comおよびGitLab Dedicatedはすでにパッチ適用済みのコードで稼働しており、これは専らセルフマネージド環境の問題である。

同じリリースでは、もう一件のクリティカルな問題——Enterprise Editionに影響するGraphQLのデシリアライゼーションの脆弱性CVE-2026-87719——と、深刻度Highの6件のバグも修正されている。ファイル読み取りのためにアップグレードする組織はこれらも同時に手に入れることになり、その点が、他を放置する回避策を探すよりもアップグレードを選ぶ理由になる。

ソース管理サーバー上のファイル読み取りは、ただのファイル読み取りではない

任意のファイル読み取りは通常、リモートコード実行より一段下に分類される。多くの文脈ではそれで妥当だ。だがセルフマネージドのGitLabインスタンスは「多くの文脈」ではない。それは組織が意図的に、下流のあらゆるものに到達する認証情報の保管役に据えたマシンである。CI/CD変数、デプロイトークン、Runner登録トークン、コンテナレジストリの認証情報、クラウドプロバイダーの鍵、署名用の資材、そしてそれらを結びつける設定。統合されたDevSecOpsプラットフォームの価値提案そのものが、パイプラインから到達できるよう、これらの機密情報を一箇所にまとめる点にある。

したがって、そのホストへの読み取りアクセスは、1台のサーバーへの読み取りアクセスではない。そのサーバーがデプロイする資産全体の鍵への読み取りアクセスである。GitLabのマシン上で一行もコードを実行しない攻撃者であっても、そのマシンとして他のあらゆるシステムに認証できてしまう。そしてその後の行動はすべて、パイプラインが通常業務をこなしているようにしか見えない。これが実務上の「スコープ変更」の意味であり、本件を情報漏えいのバグではなく、ディレクトリサービスの侵害と同じ枠で捉えるべき理由でもある。

パッチは扉を閉じる。だが鍵を回収はしない

ここが組織の先送りする部分であり、パッチ公開から数日を経た今この話を書く理由でもある。

19.3.2、19.2.6、19.1.8へのアップグレードは読み取りを止める。しかし、すでに読み取られたものについては何もしない。アップグレード以前に露出していたインスタンス上に置かれていた機密情報は、漏えいしたものとして扱い、ローテーションすべきだ。そして成熟したGitLab環境におけるローテーションは、長く、退屈で、部門横断的な作業になる。トークンを差し替えれば壊れて騒ぎ立てるパイプラインに片端から触れることになるからだ。まさに「来四半期に」と予定され、そのまま実行されない類の仕事である。

Rapid7はこの点を率直に述べており、アップデート適用後であっても侵害の痕跡を探すよう推奨し、CISAのBOD 26-04の下でKEV登録に付随するフォレンジック・トリアージの義務に言及している。連邦機関にはその作業が義務づけられている。それ以外の組織は、同じ攻撃者に晒されているだけだ。

アップグレードを計画する前に知っておくべき運用上の注意が2点ある。パッチにはデータベースマイグレーションが含まれるため、シングルノード構成ではダウンタイムが発生する。発生してから気づくのではなく、あらかじめ計画に織り込むべきだ。もう1点、ローテーションが必要かどうかを判断する際の基準になるのは、パッチとKEV登録の間の「1日」という数字である。インターネットに面したインスタンスが9月10日以降のいずれかの時点で未パッチだったのなら、到達されたと想定すべきだ。

より大きな論点

CISAはパストラバーサルを「悪意あるサイバー攻撃者による頻出の攻撃ベクター」と表現している。これは、この種のバグがおよそ30年にわたってよく理解されてきたにもかかわらず、人々が運用する最も機微なソフトウェアに現れ続けている、という事実の官僚的な言い換えだ。興味深い問いは、パス制限のチェックがなぜ抜け落ちたのか、ではない。なぜこれほど多くの組織が、保有するすべての認証情報を、インターネットに面した単一のWebアプリケーションの背後に集約しておきながら、そのアプリケーションが破られたときにそれらを入れ替える手順を一度も演習していないのか、である。

パッチは提供されており、修正そのものは単純だ。厄介なのはパッチの後に回ってくる請求書のほうであり、そしてそれは支払われないまま終わる。二つのうち大きいのは、後者だ。

Sources: GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 · Rapid7: CVE-2026-85706 Critical GitLab Path Traversal Exploited in the Wild · BleepingComputer: CISA — hackers now exploit max severity GitLab flaw in attacks · The Register: Perfect-10 GitLab bug under attack days after patch lands · Infosecurity Magazine: Hackers Exploit Maximum Severity Flaw in GitLab · CISA Known Exploited Vulnerabilities Catalog