GitLabの未認証RCEがKEV入り：修正版とRuby・Runnerを分けて点検する

今回の新情報は、修正版が初めて出たことではなく、CISAが実際の悪用を確認したことです。GitLabの修正発表は10月12日。そこから17日後の10月29日に、KEVへ追加された形です。さらに10月29日には、別の証明書問題を含む更新も公開されました。この記事では「どの脆弱性を、どの版が直すのか」と「GitLab本体以外に何を確認するか」を分けます。

確認時点は2026年10月30日7時台（日本時間）。根拠はGitLabの10月12日勧告、CISA KEVの公式データ、10月29日の更新告知です。本記事は公式資料の照合と防御点検の解説であり、GitLab実機への攻撃再現や本番環境の更新試験は行っていません。

CI/CDは、コードの変更に合わせてテストや配備を自動化する仕組みです。その設定には、文字列の条件を表す「正規表現」が使われることがあります。CVE-2026-97229では、細工された正規表現を処理する際の検証不足と整数オーバーフローが問題になります。

整数オーバーフローとは、数値がプログラムで扱える範囲を超えて、サイズなどの計算結果が意図しない値になることです。今回の原因は、正規表現を実行用の内部形式へ組み立てる段階にあります。GitLabは、一定の条件で未認証の相手がGitLabサーバー上のコードを実行できると説明しています。単にCIジョブが失敗するだけの問題として扱えません。

CVSS 10.0は技術的な重大さの評価で、感染率や被害件数ではありません。GitLabの勧告には特定の導入方式への限定がないため、Linuxパッケージ、コンテナ、ソースビルドなども、方式だけを理由に対象外と判断しないでください。

次の最初の3行が、CVE-2026-97229についてGitLabが明示した影響範囲と初回修正版です。右端には、後続の更新告知で確認した版を併記しました。「97229が直った」と「その時点の別の問題も直った」は別の判断です。

根拠：CVE-2026-97229の影響版、10月29日の更新版。19.1以前が97229の列に載っていないことを、GitLab全体が安全という意味に読み替えないでください。対応中の系列や更新経路を確認して更新先を決めます。

110264の影響範囲はGitLab 7.0以降から系列ごとの修正版未満まで広がります。正確な区間は10月21日の勧告で確認できます。今回取得したKEVデータで追加を確認したのは97229であり、関連するすべてのCVEが悪用確認済みという意味ではありません。

GitLabの10月29日告知は、秘密鍵が侵害されたeMudhraの中間CA証明書8件への信頼を取り消すCVE-2026-111943への対応を含みます。中間CA証明書は、接続相手の証明書を信頼できるか確かめるためのつながりの一部です。正規表現のRCEとは原因も更新対象も違います。

これらをすべて導入しているとは限りません。管理対象の有無と担当者を確認し、使っていない構成要素は「非該当」、確認できないものは「不明」と台帳に残します。更新のために証明書検証を無効にすることは勧めません。

Ruby開発元の10月23日発表は、GitLabの複数のCVEに関係する正規表現エンジンOnigmoの修正を整理しています。GitLabは、自ら配布するRubyへ修正を取り込む形で対応したと説明されています。このため、OS側でruby -vを見ただけでは、GitLabの稼働構成が修正済みかは判断できません。

Ruby全体について、開発元は関連する修正をまとめて含む版として4.0.9、3.4.12、3.3.13以降への更新を推奨しています。ただしGitLabパッケージの同梱Rubyやディストリビューションには修正のバックポートがあり得ます。上流の版番号だけで断定せず、配布元の勧告と適用パッケージを結び付けて確認してください。GitLabの同梱Rubyを手作業で差し替える手順ではありません。

自社でRubyアプリも開発している場合は、外部から届いた文字列をRegexp.new、Regexp.union、Regexp.compileなどで正規表現として組み立てる箇所を別に点検します。開発者が用意した固定の正規表現に入力文字列を照合する使い方とは異なります。Rubyは、Regexp.timeoutも入力の長さ制限も今回の問題を確実には防がないと明記しています。

1. 1資産の棚卸し：Self-Managedか、GitLab.comか、Dedicatedかを分ける。管理者、稼働版、導入方式、外部公開の有無、全ノード・コンテナ、Runner、AI Gatewayを記録する。GitLab側は管理下のGitLab.com/Dedicatedに修正済みと説明している。自社運用Runnerなどの確認は別に残る。
2. 2ログと変更履歴の保全：未修正だった期間、更新日時、接続ログ、認証・権限・トークンに関する変更を、社内の保全手順に従って確保する。疑わしい場合は通常のアップデートだけで完了にせず、インシデント対応担当へつなぐ。
3. 3更新計画：バックアップと復元方法、構成・秘密情報の別保管、必須の中間更新版、DBのバックグラウンド移行、停止時間を確認する。検証環境で手順と復元可能性を確かめる。
4. 4修正版の適用：利用方式の公式手順で、必要な停止点を経由してサポートされる修正版へ進む。Runner・AI Gateway・CIイメージが対象なら、それぞれの担当者へ作業を割り当てる。
5. 5稼働確認：更新後に実際に動いている版を全ノードで確認し、ログイン、リポジトリ閲覧、許可された試験用リポジトリのclone/push、CIジョブ、必要なレジストリ操作を検証する。
6. 6完了記録：対象資産、修正根拠URL、適用版、再起動・切替、機能検証、ログ調査、残件と担当者を記録する。画面が開くことだけを完了条件にしない。

具体的な順序や停止点はGitLab公式のアップグレード準備に従います。緊急時でも、古いメジャー版から最新版へ一度で飛ばせるとは限りません。アクセス範囲の制限を暫定的に検討する場合も、更新の代替や安全保証にはしないでください。

このコマンドは公式の環境情報収集手順に基づきます。GitLabのVersionとRuby Versionは別欄です。出力にはURLや構成情報も含まれるため、共有時は伏せます。ソースビルド、Docker、Helm/Kubernetesでは対応する手順を使い、ホストのCLIだけで稼働中コンテナの版を代用しないでください。

GitLabは97229向けに6種類の検知ルールを公開しています。たとえばOnigmo native worker crashのルールは、Puma/RailsのエラーログにあるRubyのクラッシュと関連フレームを調査の手掛かりにします。ほかにもCI設定の検証やエラー増加に関するルールがあります。まず勧告内の検知一覧から、自分のログ収集構成に合うものを選びます。

検知は調査を始めるための材料です。クラッシュの一致だけで侵害確定とせず、アクセス・認証・変更記録と突き合わせます。逆に一致がなくても、ログの保存不足や検知できない経路があるため、安全の証明にはなりません。未修正期間や影響範囲が分からない場合は、その不確実性を残して調査します。

更新は今後の入口を塞ぐ作業であり、すでに侵害された環境の復旧完了を意味しません。侵害の疑いがあれば、証拠保全、隔離の判断、復旧、認証情報の失効・再発行をインシデント対応計画に沿って進めます。本記事の確認時点で、特定企業の流出件数や侵害状況は確認していません。

空の点検台帳CSVを用意しました。これは手入力の記録表で、ネットワークへ接続したり脆弱性を自動判定したりするプログラムではありません。秘密値を含めず、実際の管理記録で埋めてください。

LLMに任せるのは、根拠と台帳の突き合わせ、抜け漏れの整理、手順案の作成です。実際の変更判断、アクセス権の確認、復旧完了の判断は担当者が行います。一般的な流れは脆弱性の初動整理、ログ確認と更新を並行する考え方はFragnesiaの悪用情報と稼働カーネルの点検も参照できます。

出典確認：2026年10月30日7時台JST。CVE-2026-97229の修正発表・提供日はGitLab告知上10月12日、関連RCEの修正は10月21日、Ruby発表は10月23日03:11:22 UTC、KEV追加は10月29日（日付のみ）、証明書対応のリリース日付は公式フィードで10月29日です。KEVの追加日を攻撃開始日や初公表日と混同していません。悪用開始日時・件数は今回の確認資料では不明です。