• 実際に悪用されている GitLab の脆弱性 CVE-2026-85706 について、CISA が設定した9月14日の修正期限はすでに過ぎた
  • GitLab の修正にはデータベース移行が必要で、単一ノード環境は停止する一方、正しい手順で更新した複数ノード環境では停止を回避できる

事実関係

実際に悪用されている GitLab の脆弱性 CVE-2026-85706 について、CISA が設定した9月14日の修正期限は過ぎた。この脆弱性により、一定の条件下では認証されていない利用者がサーバー上のファイルを読み取れる可能性がある。CISA は9月11日、この欠陥を Known Exploited Vulnerabilities カタログに追加した。この期限は、対象となる米国連邦政府の文民機関に適用される。

GitLab は9月10日、修正版 19.3.2、19.2.6、19.1.8 を公開し、影響を受ける自己管理型 GitLab の顧客に直ちにアップグレードするよう促した。GitLab.com はすでにパッチ適用済みで、GitLab Dedicated の顧客は対応する必要がない。

この更新にはデータベース移行が含まれる。GitLab によると、単一ノード構成は移行が完了するまで利用できなくなる。複数ノード構成は、運用者が同社の無停止アップグレード手順に従えば、停止せずに更新できる。

分析

自社の GitLab サーバーを運用するチームにとって、このパッチで難しいのは適用するかどうかの判断ではない。すでに進行中のリリース管理に開発者が使っている可能性のある基盤で、緊急のデータベース移行を実施する時間を確保することだ。単一ノード環境は、その作業が終わるまで停止しなければならない。

より余裕のある保守時間帯を待てば、実際に悪用されている脆弱性を未修正のまま長く残すことになる。直ちに更新すれば、リポジトリ、マージリクエスト、その他の開発作業が中断する可能性がある。複数ノード構成は柔軟性が高いが、それでも GitLab が定める正しいアップグレード順序に従う必要がある。複数のマシンがあっても、データベース変更そのものがなくなるわけではない。

BTW の読者にとって、この事案は自己管理型の開発基盤が伴う運用コストを明確に示している。組織はサーバーだけでなく、緊急保守の時間帯にも責任を負う。GitLab.com と GitLab Dedicated の顧客にはすでにセキュリティ対応が実施されている一方、自己管理型環境の運用者は同じ修正を自らのリリース日程に組み込み、その後サービスを確実に正常復旧させなければならない。

今後の注目点

自己管理型環境の運用者が、修正版の導入とデータベース移行の正常完了の双方を確認する動きを注視したい。アップグレードの遅延、移行の失敗、または GitLab からの追加案内があれば、緊急のセキュリティ対応と開発日程がどこで衝突しているかが明らかになる。パッチ適用前に悪用があったことを示す証拠が確認されれば、別途インシデント対応も必要になる。