GitLabの脆弱性CVE-2026-97229｜悪用確認、コード実行のおそれと修正版・確認方法

CVE-2026-97229は、GitLabがCI/CD設定の中の正規表現を十分に検証していないために起きる整数オーバーフロー（CWE-190）で、条件によっては認証されていない攻撃者にGitLabサーバー上で任意のコードを実行されるおそれがあります。GitLabは深刻度をCritical、CVSS v3.1の基本値を10.0としています。[1][3]

原因は、GitLabが使うRubyの正規表現エンジン（Onigmo）で、細工したパターンをコンパイルするとメモリが壊れることです。GitLabは、自社で同梱するRubyに修正を当てて直しました。[4]

対象は、自社で運用するGitLab CE/EEの19.2〜19.4の系列です。GitLabの告知は配布の形（Linuxパッケージ、ソースからの導入、Helm チャートなど）を挙げておらず、この場合はすべての形が対象です。[1]

GitLab.comはすでに修正済みの版で動いており、GitLab Dedicatedも告知の前に修正済みです。[1]

米CISAは2026年10月29日（米国時間）に、悪用の証拠に基づいてCVE-2026-97229をKEVへ追加し、米連邦政府機関の対応期限を11月1日としました。KEVでは、更新の前に侵害の有無を調べる対象（Forensic Triage）にも指定されています。[2][10]

悪用の確認とは別に、攻撃用のコードも公開されています。CI Lintを使ってGitLabでコードを実行するMetasploitのモジュールは、2026年10月14日に公開の場で提案され、10月30日（米国時間）に取り込まれました。[9]

2026年11月2日に確認した時点で、JPCERT/CCとIPAの注意喚起の一覧にこの脆弱性はありません。

GitLabは、条件によっては認証されていない攻撃者がコードを実行できるとしています。条件の詳細は公開していません（GitLabは脆弱性の課題を修正の90日後に公開します）。[1]Metasploitのモジュールの説明では、公開プロジェクトにpushできる利用者のアカウントで細工したCI設定とリポジトリのパスを置き、そのうえで認証なしのCI Lintの要求を送ると、GitLabのgitアカウントの権限でコマンドが動きます。[9]

インターネットや取引先から届き、外部の人がアカウントを作れる・公開プロジェクトがあるGitLabほど急ぎます。社内のGitLab（本番・検証・部署ごとのもの、クラウド上に立てたものを含む）を一覧にし、それぞれの版と、外から届くかを書き出します。

GitLabは、自社で運用するGitLab向けに、この脆弱性を狙った攻撃の試みを見つけるための検知ルールを6つ公開しています。[1]それぞれ、次のログの記録を手がかりにします。[6][7][8]

1. Pumaのエラーログ（puma_stderr.log）に、Onigmo（正規表現のエンジン）の関数を経由したRubyの異常終了の報告（[BUG]）が無いか
2. Workhorseのアクセスログに、/api/v4/projects/:id/ci/lint や /api/graphql へのPOSTが502（badgateway: failed to receive response: EOF）で終わった記録が無いか
3. application_json.log に、CIの正規表現の安全確認が拒否した警告（regexp rejected at compile time など）が無いか
4. graphql_json.log に、ciLint の変数として細工した正規表現（{96000,} のような大きな繰り返しなど）が送られた記録が無いか
5. api_json.log に、同じクライアントから ci/lint への5xxの応答が短い間に続いた記録が無いか
6. リポジトリのパスに、255バイト近い長さで非ASCIIの文字を含む不審なものが無いか
7. 細工した .gitlab-ci.yml をpushする経路では、Sidekiqのログに「A worker terminated, shutting down the cluster」が出て、パイプラインが作られていない記録が無いか

攻撃が成功するとワーカーが異常終了し、その要求はRailsのログ（api_json.log・graphql_json.log）に残らないことがあります。Workhorseのログも合わせて見ます。[7]

CVE-2026-97229の対象は19.2〜19.2.7、19.3〜19.3.4、19.4〜19.4.1で、19.2.8・19.3.5・19.4.2で直ります。[1][3]ただし、同じ種類の脆弱性CVE-2026-110264（認証なしのコード実行、CVSS 10.0）が7.0以降の幅広い版を対象に10月21日に直っています。[5]使っている系列の最新のパッチ版まで上げます。

GitLabのセキュリティチームは、19.4.1に入っていたCVE-2026-93577の修正が不十分で、CVE-2026-97229で回避されたとしています。19.4.1で止めず、上の版に上げます。[6]最新の版は[11]で確かめます。

1. 版を確かめる：Linuxパッケージで入れた場合は sudo gitlab-rake gitlab:env:info、ソースから入れた場合は bundle exec rake gitlab:env:info RAILS_ENV=production を実行し、「GitLab information」の Version を見ます。複数台の構成では、GitLab Railsが動くサーバーで実行します。[12]
2. 上げる：19.4.2などのパッチにはデータベースの移行が含まれます。1台構成では、移行が終わるまでGitLabが起動しないため停止時間が出ます。複数台の構成では、停止なしの手順で上げられます。[1]
3. 反映を確かめる：上げた後に同じコマンドで版が修正版以上になったことを確かめます。[12]
4. 保守の会社に頼むときは、GitLabのサーバーの台数と構成（1台か複数台か）、いまの版、上げる先の版、作業の前後でログを残しておくことを伝えます。

GitLabの告知に、CVE-2026-97229の回避策の記載はありません。GitLabは、対象の版を使うすべての環境をできるだけ早く最新の版に上げるよう強く勧めています。[1]

米CISAは、同じRuby（Onigmo）の整数オーバーフローの問題で、GitLab以外の製品も影響を受ける可能性があるとしています。[10]Rubyの開発チームは2026年10月23日に、修正を含むRuby 4.0.9・3.4.12・3.3.13を公開しました。[4]

Rubyの開発チームによると、影響を受けるのは、攻撃者が操作できる文字列から正規表現を作るアプリケーション（Regexp.new などに入力を渡すもの）だけです。Regexp.timeout や、パターンの長さの制限では防げません。上げられない場合は、信頼できない入力から正規表現を作らないよう求めています。[4]