対象：GitLabを自社のサーバーやクラウドで運用している管理者（Self-Managed）と、Rubyでアプリを作っている開発者。本記事はGitLabのパッチリリースの告知、Rubyの公式発表、米国の脆弱性データベース（NVD）、米CISAの公開情報にもとづく解説で、攻撃の手順は扱いません。
続報待ち：この記事は公式発表に合わせて更新します
2026年10月25日8時（日本時間）時点まだ分かっていないこと
- 脆弱性が成り立つ具体的な条件（GitLabは「特定の条件下で」とだけ記載）
- 悪用の有無の変化（公表時点では報告なし）
- NVDの評価（分析中）
GitLabは10月21日にパッチリリースを公開し、Rubyの開発チームは10月23日に修正版を公開しました。悪用の報告はなく、米CISAのKEVにも入っていません。詳しい技術情報は、リリースから90日後に公開されるとGitLabは書いています。状況が変わったら、この記事を更新します。
今日やること（GitLabを自前で運用している場合）
バージョンを確かめる
Linuxパッケージ（Omnibus）で入れている場合は、Railsが動くサーバーで sudo gitlab-rake gitlab:env:info を実行すると、出力の「GitLab information」にバージョンが出ます。管理者でサインインして管理エリアを開いても確かめられます。複数のサーバーで動かしている場合は、すべてのノードの版をそろえて確認します。
同じ系統の修正版に上げる
たとえば19.4.xを使っているなら19.4.3、19.3.xなら19.3.6のように、同じマイナー版の中のパッチ版へ上げます。同じマイナー版の中のパッチ更新なので、ふつうは経由版を通る必要はないと当サイトは考えています（念のため公式ツールでも確かめてください）。1台構成では、データベースの移行が終わるまでGitLabが起動しないため、停止時間が出るとGitLabは書いています。複数台構成では、無停止のアップグレード手順が使えます。
古い版からは、経由版を確かめてから上げる
GitLabは、飛ばしてはいけない経由版（アップグレードストップ）を決めています。2026年10月時点の一覧では、18系は18.2、18.5、18.8、18.11、19系は19.2、19.5、19.8、19.11です（19系のうち公開済みなのは19.2と19.5）。今の版と目標の版をGitLabのUpgrade Pathツールに入れると、通るべき版が出ます。GitLabは、後の版へ上げる前にこれらの版へ上げ、バックグラウンドの移行処理が終わるのを待つよう求めています。
すぐに上げられない場合は、外からの到達を絞る
GitLabの告知には、更新以外の回避策は書かれていません。更新までの間は、ファイアウォールやVPNで社外からGitLabに届かないようにし、新規登録を止めておくことを勧めます（当サイトの判断）。どちらも穴をふさぐものではないので、更新は別に進めます。
痕跡を確かめる
GitLabは自前運用の利用者向けに、悪用の試みを見つけるための検知ルールを2つ公開しています（告知の「Detecting CVE-2026-110264 Exploitation Attempts」）。ログの監視の仕組みがあれば取り込みます。あわせて、身に覚えのないプロセス、ファイル、管理者アカウント、外向きの通信がないかを見ます。確かめ方はサーバーが不正アクセスされたか調べる方法にまとめています。
自分が対象かの早見表
| 使っているもの | CVE-2026-110264（Critical） | 同じリリースのHigh 2件など | 目指す版 |
|---|---|---|---|
| 19.5.x（19.5.1より前） | 対象 | 対象 | 19.5.1 |
| 19.4.x（19.4.3より前） | 対象 | 対象 | 19.4.3 |
| 19.3.x（19.3.6より前） | 対象 | 対象 | 19.3.6 |
| 19.0.xから19.2.x | 対象（19.0.10、19.1.9、19.2.9で修正） | 修正は19.3.6以降だけ | 19.3.6以降へ |
| 18.11.x（18.11.13より前） | 対象（18.11.13で修正） | 修正は19.3.6以降だけ | 19.3.6以降へ |
| 18.10以前（7.0以降） | 対象 | 版により対象 | 経由版を通って新しい版へ |
| GitLab.com | 修正済み | 修正済み | 作業不要 |
| GitLab Dedicated | 19.3.5-internal0、19.4.2-internal0以降で修正済み | 同左 | 作業不要とされている |
High 2件などの影響範囲は脆弱性ごとに違います（たとえばCVE-2026-15723は10.1以降、CVE-2026-112212は18.3以降）。正確な範囲はGitLabの告知の表で確かめてください。
今の版
修正版より前は、Criticalが残る
18.11.13〜19.2.9
Criticalは修正。Highは残る
19.3.6・19.4.3・19.5.1
このリリースの修正がすべて入る
何が公表されたのか（GitLabの告知より）
- CVE
- CVE-2026-110264（CWE-190：整数オーバーフロー）
- 深刻度
- Critical、CVSS v3.1で10.0（AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H、GitLabの評価）
- 内容
- 細工された正規表現をコンパイルするときの整数オーバーフローにより、特定の条件下で、認証していない利用者がGitLabサーバー上で任意のコードを実行できるおそれ
- 対象
- GitLab CE/EEの7.0以降で、18.11.13、19.0.10、19.1.9、19.2.9、19.3.6、19.4.3、19.5.1より前
- 修正済みの環境
- GitLab.com。GitLab Dedicatedは19.3.5-internal0、19.4.2-internal0以降
- 報告
- 外部の研究者が、GitLabのバグ報奨金制度（HackerOne）を通じて報告
- 悪用
- 告知に記載なし。CISAのKEVにも未掲載（10月25日時点）
同じリリースでは、ほかに11件の脆弱性が修正されました。Highは2件です。CVE-2026-15723（CVSS 8.2）は、OmniAuthのSAMLとLDAPの自動ひも付けを両方有効にしている場合に、認証済みの利用者が既存のLDAPアカウントを乗っ取れるおそれがあるというものです。CVE-2026-112212（CVSS 7.5）は、OAuth/OIDCの設定情報を返す仕組みのキャッシュが汚染され、一部の処理が外部のサーバーへ向けられるおそれがあるというものです。残りはMediumが5件、Lowが4件です。
米CISAが10月21日付で付けた評価（SSVC）は、悪用「なし」、自動化「可能」、技術的な影響「全面的」です。悪用の報告がない今のうちに更新を終えるのが、いちばん手間の少ない対応です（当サイトの見方）。
原因はRubyの正規表現エンジン：Rubyのアプリを作っている人へ
Rubyの開発チームは10月23日、正規表現エンジン（Onigmo）の不具合を直したRuby 4.0.9、3.4.12、3.3.13を公開しました。GitLabが付けた4つのCVE（CVE-2026-89078、CVE-2026-93577、CVE-2026-97229、CVE-2026-110264）に関係する、3つの不具合の修正です。CVE-2026-110264以外の3つは、GitLab 19.4.1と19.4.2で修正されたものです。
Regexp.timeoutでは防げない
Rubyの発表によると、この不具合に当たるのは、攻撃者が操作できる文字列から正規表現を作るアプリだけです（Regexp.new、Regexp.union、Regexp.compile、/#{input}/ のような埋め込み）。開発者が書いた正規表現だけを使うアプリは対象外です。正規表現の処理時間を制限するRegexp.timeoutでは防げず、パターンの長さを制限しても確実ではないとされています。
Ruby 3.3は本来セキュリティ修正だけの時期ですが、GitLabがCVEを付けた問題に関係するため、例外として3.3.13に修正が入りました。Ruby 3.2は2026年4月1日にサポートが終わっていて、修正版は出ていません。
GitLabのLinuxパッケージとクラウドネイティブ版のイメージには、GitLab側で正規表現の修正が入っています。GitLabの管理者は、サーバーのRubyではなくGitLab本体を更新します。ソースからGitLabを入れている場合は、使っているRubyも修正版に上げておくことを勧めます（当サイトの判断）。
危ない書き方
- 検索欄やフィルタの入力を、そのままRegexp.newに渡す
- 利用者が登録したパターンを、サーバー側の正規表現として動かす
- Regexp.timeoutや長さ制限があるから大丈夫と考える
- サポートが終わったRuby 3.2以前を使い続ける
影響を受けにくい書き方
- 文字列として探すだけなら、Regexp.escapeで記号を無効にしてから使う
- 利用者に正規表現を書かせる機能は、本当に必要か見直す
- 必要なら、別の正規表現エンジンや分離したプロセスで動かす（当サイトの見方）
- Rubyを4.0.9、3.4.12、3.3.13以降に上げる
使っているgemやフレームワークの中で、利用者の入力から正規表現を作っていないかは、自分のコードだけを見ても分かりません。Rubyを上げるのがいちばん確実です。依存の脆弱性を見張る仕組みはosv-scannerで依存のCVEを機械監視する方法にまとめています。
自前のGitサーバーで忘れられがちなこと
自前でGitLabを動かすと、リポジトリの誤公開のような事故は減らせますが、パッチを当てる責任は自分に移ります。今回のように7.0以降のほぼすべての版が対象になる脆弱性では、更新を止めていた古いサーバーほど、経由版が多く、作業が重くなります。
当サイトの判断では、少なくとも経由版（アップグレードストップ）の1つ手前までは、ふだんから追いついておくのが現実的です。そうしておけば、緊急のときに上げる版が1つか2つで済みます。自前運用とGitHubの比較は自前のGitサーバーとGitHub、セキュリティ的にどっちが安全かを参照してください。
まだ分かっていないこと
| 項目 | 状態 |
|---|---|
| 脆弱性が成り立つ具体的な条件 | 記載なし（「特定の条件下で」とだけ記載。詳細はリリースから90日後に公開予定） |
| 悪用の有無 | 記載なし（CISAのKEVにも未掲載、10月25日時点） |
| 公開されている攻撃コード | 記載なし |
| NVDの評価 | 分析中（GitLabの評価は10.0） |
| Rubyの不具合自体へのCVE | Rubyの開発チームはまだ申請していない（今後見直す可能性あり） |
出典
- GitLab「GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13」（2026年10月21日） — docs.gitlab.com
- Ruby「Regexp compilation fixes related to GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264」（2026年10月23日） — ruby-lang.org
- Ruby「Ruby Maintenance Branches」（各版のサポート状況） — ruby-lang.org
- GitLab「Upgrade paths」（必須の経由版） — docs.gitlab.com
- GitLab「Maintenance Rake tasks」（gitlab:env:info） — docs.gitlab.com
- NIST NVD「CVE-2026-110264」 — nvd.nist.gov
- 米CISA「Known Exploited Vulnerabilities Catalog」 — cisa.gov
更新履歴
2026-10-25：初版。GitLabのパッチリリースの告知、Rubyの公式発表、NVD、米CISAのKEV（2026年10月23日版）にもとづく。
次に読む
- 自前運用の考え方：自前のGitサーバーとGitHub、セキュリティ的にどっちが安全か
- 優先順位の決め方：CVEの直す順番の決め方（CVSS・EPSS・KEV）
- 侵害の確かめ方：サーバーが不正アクセスされたか調べる方法
- 同じ時期の言語の修正：PHP脆弱性 CVE-2026-109618・CVE-2026-109619
- 用語：RCE（リモートコード実行）とは ／ CVSSとは