GitLab に CVSS 10.0 の緊急パッチ ― 正規表現コンパイラの整数オーバーフローとは何か、今すぐやるべきこと

はじめに：2026年10月21日、GitLab が7バージョン同時リリース

2026年10月21日、GitLab は 19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13 の7バージョンを同時リリースし、CVSS スコア 10.0（満点） の脆弱性を含む合計12件のセキュリティ問題を修正しました。

この脆弱性は 認証不要・ネットワーク経由・完全なリモートコード実行（RCE） が可能という最悪の組み合わせを持ち、Censys の調査では公開インターネット上で 25,766 台 の脆弱なホストが確認されています。さらに Rapid7 がすでに動作する PoC（Proof of Concept）を公開しており、猶予はほとんどありません。

本記事では次のことを段階的に解説します。

• インフラ担当者・SRE の方：アップグレード手順と緩和策 → 「Self-Managed 版のアップグレード手順」「パッチを今すぐ当てられない場合」へ
• 開発者・セキュリティエンジニアの方：脆弱性の仕組みと攻撃フロー → 「整数オーバーフローの仕組み」「攻撃はどう成立するのか」へ
• まず要点だけ知りたい方：記事末尾の「まとめ：今日やるべきことチェックリスト」へ

今回のパッチで修正された12件の脆弱性

中心となる2件の CVSS 10.0 脆弱性

今回のリリースで特に注目すべき脆弱性は以下の2件です。

CVE-2026-97229 は以前のパッチで部分的な対応が行われていましたが、同一エンジン（Ruby の Onigmo 正規表現エンジン）の別トリガーによる問題が残っており、今回の CVE-2026-110264 としてあらためて修正されました。

自分の環境が対象かを30秒で確認する方法

影響範囲は GitLab 7.0 以降のすべてのバージョン、すなわち約12年分のリリースが対象です。まず現在のバージョンを確認しましょう。

# Self-Managed の場合（管理者権限のターミナルで実行）
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A 5

# または Web UI から確認
# Admin Area → Dashboard → Components → GitLab

表示されたバージョンが上記7バージョンのいずれかより古い場合は、即時アップグレードが必要です。

CVSS スコア 10.0 が意味するリスクレベル

CVSS スコア帯と対応優先度の対応表

なぜ「満点」なのか ― 10.0 が付く3条件

CVSS スコアが 10.0 の満点になるには、次の3条件がすべて揃う必要があります。

1. ネットワーク経由で攻撃可能（Attack Vector: Network）：攻撃者はターゲットと物理的に隣接している必要がなく、インターネット越しに攻撃できます。
2. 認証不要（No Privileges Required）：GitLab に有効なアカウントを持たない外部の攻撃者でも悪用できます。
3. 完全なシステム制御（機密性・完全性・可用性すべてに最大影響）：攻撃が成功した場合、ソースコードの窃取から任意コマンドの実行まで、あらゆる権限を掌握される可能性があります。

今回の CVE-2026-110264 はこの3条件をすべて満たしているため、最高スコアが付与されています。

現実のリスク：PoC 公開済みで猶予は短い

Censys の調査によれば、公開インターネット上で 25,766 台 のホストが脆弱なバージョンの GitLab を稼働させています。そして Rapid7 がすでに動作確認済みの PoC をリリースしており、攻撃のハードルは大幅に下がっています。「公開されてから攻撃が来るまでの時間」は年々短縮されており、実際の開発現場では「PoC 公開 = 攻撃が始まっている」と考えて行動するのがベストプラクティスです。

整数オーバーフローの仕組みと危険性

そもそも整数オーバーフロー（CWE-190）とは

整数オーバーフローとは、変数が表現できる最大値を超えた際に値が「一周」してしまうバグです。たとえば符号なし8ビット整数（0〜255）の場合、255 + 1 を計算すると 256 ではなく 0 になります。

// 分かりやすい概念例
uint8_t size = 200;
uint8_t extra = 100;
uint8_t total = size + extra; // 期待値: 300 → 実際: 44（オーバーフロー）

// この「44」を信じてバッファを確保すると、
// 実際に必要な300バイト分のデータが44バイトの領域に書き込まれてしまう
char *buf = malloc(total); // 44バイトしか確保されない

技術的に正確な表現をすると、整数オーバーフローはそれ自体では直接的な被害をもたらさないことが多いですが、サイズ計算に使われた場合に「想定より小さなバッファ」が確保されることで、後続のメモリ操作と組み合わさった途端に深刻な脆弱性となります。

なぜメモリ破壊から RCE につながるのか

サイズ計算が誤った結果、確保されたバッファが必要量より小さくなると、ヒープ領域のオーバーフロー（Heap Buffer Overflow） が発生します。ヒープ領域には関数ポインタや制御情報が格納されており、これを上書きすることで プログラムの制御フローを改ざん できます。最終的に、攻撃者が用意したシェルコードや任意コマンドが GitLab プロセスの権限（git ユーザー）で実行される、というのが RCE 成立までの流れです。

攻撃はどう成立するのか ― 5ステップで見る侵入フロー

CVE-2026-110264 の攻撃フローを具体的なステップで見ていきましょう。

Step 1：悪意ある正規表現を含む .gitlab-ci.yml をプッシュ 攻撃者は細工した正規表現パターンを .gitlab-ci.yml に埋め込み、任意のブランチやフォークにプッシュします。

Step 2：US-ASCII でコンパイルされ、サイズチェックを「通過」してしまう GitLab がこの正規表現を最初に検証する段階では US-ASCII エンコーディング でコンパイルされます。このとき計算されるバッファサイズは正常な範囲に収まり、バリデーションを通過します。

Step 3：UTF-8 を含むリポジトリパス評価時に Onigmo エンジンが再コンパイル UTF-8 文字を含むリポジトリパスを評価する段階になると、Onigmo エンジンは同じ正規表現を UTF-8 モードで再コンパイル します。これは最初の検証後に行われるため、TOCTOU（Time-of-Check to Time-of-Use）的な構造上のギャップが生まれます。

Step 4：再コンパイル時に整数オーバーフローが発生しメモリ破壊 UTF-8 モードでのサイズ計算において、細工された正規表現が整数オーバーフローを引き起こします。結果として必要なバッファより大幅に小さな領域が確保され、ヒープ破壊が発生します。

Step 5：git ユーザー権限で OS コマンド実行（RCE 成立） 制御フローが書き換えられ、攻撃者が意図したコードが git ユーザーの権限で実行されます。この段階で ソースコードの全量窃取、CI パイプラインへの悪性コード注入、さらには内部ネットワークへのラテラルムーブメント（横展開） が可能になります。

GitLab.com と Self-Managed の対応差異

「社内ネットワークにしか公開していないから安全」は成り立つのか

内部ネットワーク限定の公開であっても、以下の理由から安全とは言い切れません。

• 内部に侵入した攻撃者や悪意を持った内部関係者によるラテラルムーブメントの踏み台になりうる
• VPN 接続を持つ外部委託先や協力会社のアカウントが侵害された場合、内部ネットワーク経由で攻撃が成立する
• 「認証不要」の脆弱性は、内部ネットワーク上の未認証アクセスポイントからも悪用されうる

技術的に正確な表現をすると、公開面の縮小は「攻撃面を減らす緩和策」ではありますが、根本的な解決にはなりません。

Self-Managed 版のアップグレード手順

事前準備チェックリスト

□ データベース・リポジトリ・設定ファイルのバックアップを取得
□ バックアップからの復旧手順を事前に確認・テスト
□ 現行バージョンから 19.5.1 へのアップグレードパスを確認
  （GitLab は複数メジャーバージョンをまたぐ場合は段階的アップグレードが必要）
□ メンテナンスウィンドウを関係者に告知
□ ロールバック手順を準備

Linux package（Omnibus）でのアップグレード

実際の開発現場でよく使われる Omnibus パッケージの場合、以下の手順でアップグレードできます。

# 1. パッケージリストを更新
sudo apt-get update

# 2. GitLab EE の場合
sudo apt-get install gitlab-ee=19.5.1-ee.0

# GitLab CE の場合
sudo apt-get install gitlab-ce=19.5.1-ce.0

# 3. 設定を反映
sudo gitlab-ctl reconfigure

シングルノード構成 vs マルチノード構成

• シングルノード：データベースのマイグレーション完了まで ダウンタイムが発生します。あらかじめユーザーへの告知と、メンテナンスページの設定をお勧めします。
• マルチノード（HA構成）：GitLab 公式の「ゼロダウンタイムアップグレード手順」が適用可能です。Sidekiq の停止順序やデータベースマイグレーションのタイミングに注意して進めてください。

アップグレード後の検証

# 全体的な整合性チェック
sudo gitlab-rake gitlab:check

# バージョン確認
sudo gitlab-rake gitlab:env:info

# Gitaly の動作確認
sudo gitlab-rake gitlab:gitaly:check

バージョン表示・CI パイプラインの実行・認証連携（SAML/LDAP）の動作を実際に確認してから、メンテナンスモードを解除するのがベストプラクティスです。

パッチを今すぐ当てられない場合の一時的な緩和策

何らかの事情でアップグレードを即時実施できない場合、以下の緩和策を組み合わせて攻撃面を最小化してください。

□ 匿名ユーザーによるパブリックプロジェクト作成を無効化
  （Admin Area → Settings → General → Visibility and access controls）

□ 未信頼ユーザーの CI/CD 設定書き込み権限を制限
  （プロジェクトごとに「Protected branches」と「CI/CD permissions」を見直す）

□ インターネット公開面を縮小
  - WAF（Web Application Firewall）で不審なリクエストをブロック
  - IP 制限・VPN 経由のアクセスのみ許可
  - GitLab の公開ポートを最小限にする

重要：これらはあくまで一時的な措置です。「緩和策を入れたから当面は大丈夫」と考えるのは危険であり、パッチ適用が唯一の根本的な対処です。できる限り早くアップグレードの計画を立ててください。

侵害の痕跡（IoC）を確認する

パッチ適用と並行して、すでに攻撃を受けていないかの確認も重要です。

確認すべきログと異常な挙動

# GitLab の application.log で異常なアクセスを確認
sudo tail -n 1000 /var/log/gitlab/gitlab-rails/application.log | grep -E "(error|exception|RCE|exploit)"

# git ユーザーによる不審なプロセスを確認
sudo ps aux | grep git

# 最近変更された .gitlab-ci.yml を確認（例：過去24時間）
find /var/opt/gitlab/git-data/repositories -name "*.gitlab-ci.yml" -mtime -1

不審な .gitlab-ci.yml の変更履歴をたどる

GitLab の Web UI から Admin Area → Overview → Projects で最近のプッシュ履歴を確認し、不審な .gitlab-ci.yml の変更がないかを調べましょう。特に短時間に大量のプッシュが行われているプロジェクトや、普段使われていないブランチへのコミットには注意が必要です。

侵害が疑われる場合の初動対応

侵害の痕跡を発見した場合、または侵害の可能性が否定できない場合は、以下を速やかに実施してください。

□ すべての Personal Access Token・Deploy Token・CI/CD Variables を無効化・再発行
□ SSH 鍵のローテーション
□ 管理者アカウントのパスワード変更と MFA の強制
□ CI/CD パイプラインの一時停止
□ インシデントレスポンス手順の開始（社内 CSIRT または外部の専門家への連絡）

正規表現コンパイラ脆弱性の過去事例

WebKit の RegExpCachedResult 整数オーバーフロー

正規表現エンジンの整数オーバーフローは今回が初めてではありません。WebKit の JavaScript エンジン（JavaScriptCore）では、RegExpCachedResult の leftContext / rightContext プロパティが未初期化状態になる整数オーバーフローが発見されました。この脆弱性は JavaScript コードを通じて RCE に到達できるものであり、ブラウザエンジンという極めて広い攻撃面を持つことから深刻視されました。

なぜ正規表現エンジンは繰り返し狙われるのか

段階的に理解を深めていきましょう。正規表現エンジンが脆弱性の温床になりやすい理由は、その複雑さにあります。

1. 複雑な状態機械：正規表現エンジンは NFA（非決定性有限オートマトン）や DFA（決定性有限オートマトン）を動的に構築します。状態遷移の数が指数的に増えるケースがあり、バッファサイズの計算を誤りやすい構造です。
2. エンコーディング変換という「境界」：今回のように US-ASCII と UTF-8 の間でコンパイルを切り替える際、文字の幅（バイト数）が変わるためサイズ計算が再度必要になります。この「再計算」のタイミングが TOCTOU 的なギャップを生みます。
3. ユーザー入力を直接受け入れる設計：CI/CD パイプラインの定義ファイルのように、ユーザーが記述した正規表現をそのままエンジンに渡す設計は本質的にリスクを抱えています。

開発者への教訓：ユーザーが入力した正規表現を信頼してエンジンに渡す設計は避け、サンドボックス化や入力の厳格な検証・サイズ制限を設けることがベストプラクティスです。

同日に発生した PHP の脆弱性 ― 重なるセキュリティ対応をどう捌くか

2026年10月21日は GitLab の緊急パッチと同日に PHP の重要な脆弱性も発表されており、セキュリティ担当者にとってトリアージが必要な状況になりました。複数の緊急対応が重なった場合の優先度付けには、CVSS スコアだけでなく以下の軸を加味することを推奨します。

この判断軸で見ると、GitLab の今回の脆弱性は「即時対応」の優先度が最も高いと判断できます。

まとめ：今日やるべきことチェックリスト

□ 1. 自社 GitLab のバージョンを確認する
     sudo gitlab-rake gitlab:env:info

□ 2. Self-Managed なら最優先でアップグレードする
     sudo apt-get install gitlab-ee=19.5.1-ee.0

□ 3. 公開面を縮小し、緩和策を並行して実施する
     - 匿名ユーザーのプロジェクト作成を無効化
     - CI/CD 書き込み権限を制限
     - WAF・IP 制限を設定

□ 4. ログを確認し、侵害の痕跡を探す
     - application.log の確認
     - 不審な .gitlab-ci.yml の変更履歴を確認
     - 侵害の疑いがあればトークン・鍵をローテーション

□ 5. 今後に向けてパッチ適用フローを自動化する
     - Dependabot / Renovate による定期チェック
     - CVE ウォッチの自動通知設定
     - 月次のセキュリティアップデート適用サイクルを確立

よくある質問（FAQ）

Q. GitLab.com を使っていますが何かすべきことはありますか？ A. GitLab.com（SaaS 版）はリリース前にパッチが適用済みです。ユーザー側での対応は不要です。ただし、万一異常な挙動や不審なアクティビティに気づいた場合は GitLab サポートに報告してください。

Q. 19.5.1 以外のバージョンでも修正されていますか？ A. はい。19.4.3 / 19.3.6 / 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13 にも同様の修正が含まれています。これらのバージョンのいずれかへのアップグレードで対応できます。ただし、将来のサポート継続性の観点から最新の 19.5.1 へのアップグレードを推奨します。

Q. CI/CD を使っていなければ影響はありませんか？ A. CI/CD を有効化していない場合、攻撃の主要な入口である .gitlab-ci.yml を利用した攻撃は成立しにくくなりますが、同時に修正された他の脆弱性が存在するため、アップグレード自体は必要です。

Q. アップグレードにどれくらいのダウンタイムが必要ですか？ A. シングルノード構成の場合、規模にもよりますが一般的に 15〜60分程度 のダウンタイムが発生します。大規模なデータベースを持つ環境ではそれ以上になる場合もあります。マルチノード（HA）構成ではゼロダウンタイムアップグレードが可能です。

Q. すでに攻撃を受けていないか、どう判断すればよいですか？ A. application.log の確認、不審な .gitlab-ci.yml のコミット履歴の確認、git ユーザーによる不審なプロセスの有無が主要な確認ポイントです。確信が持てない場合は、すべての認証情報（トークン・SSH 鍵）をローテーションしたうえで、セキュリティ専門家によるフォレンジック調査を検討してください。

参考リンク

• GitLab 19.5.1 パッチリリースノート（公式）
• The Hacker News: Critical GitLab Flaw (CVSS 10.0)
• Rapid7: CVE-2026-97229 技術分析
• NVD: CVE-2026-110264
• CWE-190: Integer Overflow or Wraparound
• GitLab アップグレードパス確認ツール（公式）