ソフトウェアの開発基盤であるGitLabに、深刻度が最高の「CVSS 10.0」と評価された脆弱性が見つかりました。攻撃者がログインせずに、GitLabサーバー上でプログラムを実行できる危険があります。
対象は2014年のGitLab 7.0までさかのぼる広い範囲です。GitLabは2026年10月21日に修正版を公開し、自社などでGitLabを運用する管理者へ早急な更新を求めています。10月12日の緊急更新を適用済みでも、今回の更新が必要です。
ログインの手前で悪用される欠陥
今回の脆弱性は「CVE-2026-110264」です。GitLabの公式発表によると、細工された正規表現を処理する際の整数オーバーフローによって、認証していない攻撃者がサーバー上で任意のコードを実行するおそれがあります。
正規表現は、文字列を一定のパターンで探したり照合したりするための記法です。整数オーバーフローは、計算した値がプログラムで扱える範囲を超えてしまう不具合を指します。今回はこの処理の欠陥が、外部からのコード実行につながります。
GitLabの検知資料では、Org-mode形式（拡張子.org）の文書を表示用に処理する機能が攻撃経路として説明されています。細工された文書の処理によって、Rubyの正規表現エンジン「Onigmo」で本来の範囲外へのメモリ書き込みが起き、GitLabの実行アカウント（git）でコードを実行される仕組みです。
CVSSは脆弱性の深刻度を評価する指標です。今回はネットワーク経由で攻撃でき、事前の権限も、利用者に何かをクリックさせる操作も不要と評価されています。対策の中心はサーバーの更新です。パスワード変更や二要素認証だけでは、この欠陥を修正できません。
10月12日に修正された「CVE-2026-97229」は、CI/CD設定の正規表現に関する別の脆弱性です。当時の修正版である19.4.2、19.3.5、19.2.8も、今回の影響範囲に入ります。
10月24日に確認したGitLabの公式発表とCERT-EUの勧告には、今回の脆弱性を使った侵害事例の記載はありません。
影響するバージョン
対象はGitLab Community Edition（CE）とEnterprise Edition（EE）です。GitLab 7.0は2014年6月のリリースで、影響範囲は約12年分に及びます。修正版は次のとおりです。
| 影響を受けるバージョン | 今回の修正版 |
|---|---|
| 7.0以上、18.11.13未満 | 18.11.13 |
| 19.0系の19.0.10未満 | 19.0.10 |
| 19.1系の19.1.9未満 | 19.1.9 |
| 19.2系の19.2.9未満 | 19.2.9 |
| 19.3系の19.3.6未満 | 19.3.6 |
| 19.4系の19.4.3未満 | 19.4.3 |
| 19.5系の19.5.1未満 | 19.5.1 |
出典：GitLabの10月21日付リリース情報。表は今回の脆弱性を修正したバージョンです。古い版からの更新には、途中のバージョンを経由する手順が必要です。
対応は利用形態で分かれます。
-
- 自社・自宅・クラウド上で運用するGitLab：管理者が更新します。クラウドの仮想サーバーに自分でインストールしたGitLabも含まれます。
- GitLab.com／GitLab Dedicated：GitLabの発表では修正済みです。
- 外部業者に運用を委託したGitLab：委託先へ、適用したバージョンと更新完了日時を確認します。
現在のバージョンは、ログイン後の「Help（ヘルプ）→ Help」で確認できます（公式手順）。
ハッキングが波及する危険性
GitLabは、プログラムのソースコードを保管するだけの場所ではありません。変更を検査し、プログラムを組み立て、本番環境へ送り出す作業まで自動化できます。この仕組みがCI/CDです。
そのため、侵入後に攻撃者がコードや自動処理の設定を書き換えられると、不正な処理が製品や配布ファイルへ混入する危険があります。開発チームの被害が、そのソフトウェアを使う企業や利用者に広がる経路です。
もう一つの問題は、GitLabから接続する先の認証情報です。CI/CDでは、クラウドの操作や本番環境への配備に使うトークン・鍵を扱います。GitLabの技術資料は、CI/CD変数がデータベースに暗号化して保存され、対応する秘密情報ファイルがあれば復号できることを説明しています。サーバーへの侵入によって両方を取得される構成では、接続先への不正アクセスにもつながります。
こうした波及を抑えるには、配備用の認証情報に与える権限を絞り、開発環境と本番環境の接続を必要最小限にします。サーバーを更新するとともに、GitLabがどこまで操作できる構成になっているかを点検することが重要です。
管理者が優先する対応
EU機関のサイバーセキュリティを担うCERT-EUは10月22日の勧告で、インターネットに公開しているサーバーから優先的に更新し、侵入の有無も調べるよう求めています。
1．更新までの間、接続できる相手を絞る
すぐに更新できないサーバーは、ファイアウォールなどで接続元を社内ネットワークやVPN経由に限定し、外部から到達できる範囲を狭めます。これは更新までの暫定措置です。インターネットに公開している環境を優先し、検証用・休眠中のサーバーも対象に含めます。
2．バックアップを確保し、適切な手順で修正版へ更新する
データに加え、設定ファイルと暗号化に使う秘密情報ファイルをバックアップします。古いバージョンから更新する場合は、公式のアップグレード経路に沿って必要な中間バージョンを経由し、各段階のデータベース移行を完了させます。
更新後はバージョン表示だけでなく、ログイン、リポジトリの取得・書き込み、CI/CDジョブの動作まで確認します。バックアップから動作確認までの流れは、GitLabの更新前チェックにまとまっています。
3．更新と並行して、不審な操作を調べる
アクセスログや監査ログ、ジョブの実行履歴を保全し、身に覚えのないアカウント・トークン・SSH鍵の追加、コードやCI/CD設定の変更、不審な外部通信を調べます。GitLabは今回の攻撃試行を検知するために、Onigmo native worker crashとOrg mode render error burstという二つの検知ルールを公開しています。調査では次の記録を突き合わせます。
-
- 文書処理のタイムアウト：
exceptions_json.logで、同じ接続元による.org文書の処理が繰り返しタイムアウトしていないかを調べます。公式ルールは30分以内に5回以上の該当エラーが発生した場合を検知対象としています。 - 処理プロセスの異常終了：
puma_stderr.logで、[BUG]とともにorg-rubyやOnigmo関連の処理が記録されていないかを調べます。このログが監視システムの収集対象に含まれているかも確認します。 - 文書へのアクセス時の502エラー：リクエストを中継するWorkhorseのログで、
.org文書へのアクセスと502エラーの時刻・接続元を照合します。処理プロセスが途中で落ちると、そのリクエストがRails側のアクセスログに残らないことがあります。
- 文書処理のタイムアウト：
攻撃が成功しても異常終了しない場合があるため、クラッシュの記録だけで調査を終えず、アカウントやコードの変更履歴も併せて確認します。
4．侵入や認証情報の漏えいが疑われる場合は、接続先まで対応する
不審なサーバーを隔離し、組織のセキュリティ担当者と調査を進めます。流出した可能性のあるトークンや鍵は、利用先と停止の影響を把握したうえで失効・再発行します。GitLabだけでなく、その認証情報で操作できるクラウドや本番環境のログ、配布済みの成果物も調査対象です。
修正版を入れても、盗まれた認証情報や改ざんされたファイルは元に戻りません。侵入が疑われる環境では、更新と被害調査をセットで進めます。認証情報や不審な操作の調査項目は、GitLabのインシデント対応ガイドが参考になります。
一般の利用者・開発者ができること
会社や研究室のGitLabを利用している場合は、運用担当者に「CVE-2026-110264への更新は完了しているか」を確認します。具体的な識別番号を伝えることで、10月12日の別の更新との取り違えを防げます。
プロジェクトを管理している人は、最近のコード変更やCI/CD設定、追加されたメンバー・鍵・トークンを点検してください。不審な変更やジョブを見つけたら実行を止め、日時や対象を管理者へ伝えます。GitLabを開発基盤として守ることが、その先で動く製品と利用者を守ることにつながります。
最近は脆弱性の発見やパッチのアナウンスが特に多いですね…。