自社サーバーで動かすGitLabは修正版へ更新を

GitLabは、ソフトウェアの設計図にあたるソースコードを保管し、複数人で開発を進めるためのサービスだ。GitLab社が運営するクラウド版「GitLab.com」と、企業や団体が自分たちのサーバーに入れて使う「自己管理型（セルフマネージド）」がある。今回、対応が必要になるのは後者だけだ。

見つかった欠陥は、GitLabの中で「正規表現」を扱う部分にあった。正規表現とは、「数字が3桁続く」のような文字のパターンを書き表す記法で、検索や入力チェックに広く使われる。GitLab社の説明では、細工した正規表現を機械向けの形に変換（コンパイル）する途中で、数値が想定の上限を超えてあふれる「整数オーバーフロー」が起きる。その結果、特定の条件がそろうと、ログインしていない第三者がGitLabのサーバー上で任意のプログラムを動かせるおそれがあるという。

深刻さを示す「CVSS」は、脆弱性の危険度を0から10の数値で表す業界共通の指標だ。CVE-2026-110264の評価は満点の10.0。ネットワーク経由で、アカウントも利用者の操作もなしに攻撃でき、情報の流出・改ざん・システム停止のいずれも被害が最も大きい区分に入る。サーバーを乗っ取られれば、保管しているソースコードや、ほかのシステムにつなぐための認証情報まで抜き取られかねない。

GitLab社は、自己管理型のすべての利用者に対し、修正版のいずれかへ「すぐに」上げるよう強く勧めている。修正版は使っている系列ごとに決まっていて、更新先は次のとおりだ。

いま使っているバージョン	更新先の修正版
19.5系（19.5.1より前）	19.5.1
19.4系（19.4.3より前）	19.4.3
19.3系（19.3.6より前）	19.3.6
19.2系（19.2.9より前）	19.2.9
19.1系（19.1.9より前）	19.1.9
19.0系（19.0.10より前）	19.0.10
7.0〜18.11系（18.11.13より前）	18.11.13

一方、クラウド版のGitLab.comはすでに修正済みのバージョンで動いている。GitLab社が企業ごとに専用の環境を用意して運用する「GitLab Dedicated」も、内部向けのバージョン19.3.5-internal0と19.4.2-internal0以降なら修正が入っており、対応は不要とされた。自社でサーバーを持たず、GitLab.comにログインして使っているだけの会社や個人は、何もしなくてよい。

7.0から約12年分、サポート外の旧版にも修正

影響を受けるのは、無償で公開されている「Community Edition」と、有償の機能を含む「Enterprise Edition」の両方で、7.0以降のうち各系列の修正版より前のすべてのバージョンになる。GitLab 7.0が公開されたのは2014年6月。ここから数えて約12年分のバージョンが対象になった。

GitLab社は通常、最新バージョンとその前の2つの月例版、つまり10月22日時点では19.5・19.4・19.3の3系列にしかセキュリティ修正を出さない。今回はこれに加え、18.11.13、19.0.10、19.1.9、19.2.9にも特例で修正を移した。同社の保守方針で、こうした範囲外の古いバージョンへの移植は例外扱いと定められている。

なぜ12年もさかのぼるのか。

原因は、GitLabの土台になっているプログラミング言語Rubyの正規表現エンジン「Onigmo」にあると報じられた。GitLab社の修正内容の一覧にも、各修正版にRubyの正規表現に関するパッチを加えた旨が並ぶ。このエンジンを長年同梱してきたため、7.0以降のどのバージョンにも同じ欠陥が残っていたという。

注意したいのは、7.0から18.10までの古いバージョンを使っている場合だ。更新先は18.11.13になるが、GitLabは途中で必ず経由しなければならないバージョン（必須の中継点）を定めている。18.8以降のバージョンなら18.11.13へ直接上げられるものの、それより前のバージョンからは一足飛びには上げられない。古いバージョンほど、何段階かに分けて更新する手間と時間を見込んでおきたい。

10月12日の更新を当てても、また対象に

見落としやすいのが、10月21日の9日前に出た更新との関係だ。GitLab社は米国時間10月12日にも緊急の修正版19.4.2、19.3.5、19.2.8を公開し、別の脆弱性「CVE-2026-97229」をふさいでいた。こちらもCVSS 10.0で、ログインなしにサーバー上でコードを実行されるおそれがある欠陥だった。

ところが、10月12日の修正版はいずれも今回の影響範囲に入る。今回の修正版19.4.3、19.3.6、19.2.9は、10月12日に出たバージョンのちょうど1つ先の番号にあたる。急いで12日の更新を当てた管理者も、もう一度上げ直さなければならない。

逆の落とし穴もある。CVE-2026-97229の影響は19.2以降に限られ、19.1以前のバージョンはこの緊急の欠陥の対象外だった。今回はその古いバージョンまで巻き込まれている。

一連の欠陥を報告したのは、「joaxcar」の名前で活動する研究者だった。報奨金制度の運営サービスHackerOne経由で届け出た正規表現まわりのコード実行の欠陥は、9月23日の更新で直ったCVSS 9.9の2件（いずれもログインが必要）、10月12日のCVE-2026-97229、そして今回のCVE-2026-110264と、約1か月の修正分だけで4件にのぼる。前の3件は19.2以降のバージョンにとどまっていた。19.2より前のバージョンに及ぶのは、今回が初めてとなる。

確実な対策は修正版への更新

GitLab社は、修正版の発表文では攻撃が成り立つ「特定の条件」を説明しておらず、設定変更などで当面をしのぐ回避策も載せていない。同社のセキュリティチームが併せて公開した検知ルールの解説では、修正版を当てるまでの間、ログインなしで誰でも見られる「公開」設定のプロジェクトをできるだけ減らすよう勧めているが、それで安全になるとまでは書いていない。報道でも、管理者は自社の設定を理由に「うちは大丈夫」と判断できる段階になく、修正版への更新が唯一確実な対策だと指摘された。

実際の攻撃に使われたという報告は、10月22日時点で出ていない。米国の政府機関CISA（サイバーセキュリティ・インフラストラクチャーセキュリティ庁）は、悪用が確認された脆弱性を「KEV」と呼ぶカタログにまとめている。10月21日付で更新されたカタログ（日本時間10月22日朝時点の最新版）に、CVE-2026-110264は載っていない。

ただし油断は禁物だ。同じカタログにはGitLabの脆弱性がすでに5件並び、最も新しい1件は2026年9月11日に追加されたばかり。ログインなしでサーバー内のファイルを読み取られる欠陥で、実際に悪用が確認されている。GitLabの欠陥が過去にも実際の攻撃に使われてきたことは、この記録からも分かる。

GitLab社は自己管理型の利用者向けに、攻撃の試みを見つけるための検知ルールを2種類公開した。正規表現エンジンの処理が異常終了したことを示す記録と、文書を表示する処理でエラーが短時間に続く記録を、サーバーのログから拾う仕組みだ。社内で監視の担当者がいる場合は、更新とあわせて確認を頼むとよい。

自社のGitLabのバージョンは、最近のバージョンならログインした状態で画面左のサイドバー下部にある「ヘルプ」から「ヘルプ」を選ぶと、ページ上部に表示される。更新作業では、GitLabが止まる時間にも気を配りたい。19.4.3と19.3.6はデータベースの移行作業を含み、サーバー1台で動かしている環境では、移行が終わるまでGitLabを使えなくなる。複数台で運用している場合は、GitLabの無停止更新の手順に沿えば止めずに当てられる。社内の利用者へは前もって知らせておくと混乱が少ない。

同じ更新でほかに11件、古い系列では直らないものも

10月21日の更新では、CVE-2026-110264のほかにも修正が入った。GitLab社の一覧表には計12件のセキュリティ修正が並び、深刻度の内訳は「緊急」1件、「高」2件、「中」5件、「低」4件。

「高」の1件、CVE-2026-15723（CVSS 8.2）は、1回のログインで複数のサービスを使えるようにする規格「SAML」と、社内の利用者名簿を扱う仕組み「LDAP」の間で、アカウントを自動でひも付ける設定を両方有効にしている場合に限って、ログインした利用者がほかの人のアカウントを乗っ取れるおそれがある。もう1件のCVE-2026-112212（CVSS 7.5）は、特定の条件のもとで、ログインに使う設定情報の一時保存（キャッシュ）をログインしていない第三者に書き換えられ、一部のサインインの流れを外部のサーバーへ誘導されかねない欠陥だった。

ここで気をつけたい点がある。GitLab社が示した影響範囲では、緊急の1件を除く11件はいずれも「19.3.6より前」のバージョンを含み、旧系列のバージョンへ特例で修正を移したと明記されたのは緊急の1件だけだ。バージョンや使っている製品によって当てはまる件数は違うものの、19.2.9以前の旧系列向けの修正版でふさがるのは最も深刻な1件にとどまる。11件の修正まで受けるには、19.3.6、19.4.3、19.5.1のいずれかへ上げる必要がある。

同じ時期には、Webサイトを動かすプログラミング言語PHPでも深刻な脆弱性の修正版が公開されたばかりだ。社内のサーバーやWebサービスを抱える企業には、更新作業が重なる週になった。

関連記事：【PHP脆弱性パニック】「php2shell」とは　大手Webサービスが緊急メンテ、高市総理もコメントする事態に「何が起きてる？」「個人は何をするべきなの？」にわかりやすく解説

GitLab社は、修正した脆弱性の詳しい記録を、修正版の公開から90日後に同社の課題管理ページで公開する決まりにしている。ただ、先に触れた検知ルールの解説には、欠陥の仕組みがすでにかなり具体的に書かれている。90日の猶予があるとは考えず、早めに更新を済ませておきたい。

[文/構成 by MediaDogs編集部]