GitLabの重大な脆弱性 CVE-2026-97229と対応

先に要点

自社のサーバーで動かしている GitLab（セルフホスト版）に、認証なしでサーバー上のコードを実行されうる重大な脆弱性（CVE-2026-97229、CVSS 10.0）があります。2026年10月29日に CISA の「悪用が確認された脆弱性」の一覧（KEV）に追加され、対応の期限は11月1日、侵害の調査（フォレンジックのトリアージ）も求められています。
10月12日の修正版（19.4.2・19.3.5・19.2.8）に上げただけでは足りません。10月21日にも、同じ種類の別の脆弱性（CVE-2026-110264、CVSS 10.0）が修正されています。上げ先の最低ラインは 19.5.1・19.4.3・19.3.6・19.2.9・19.1.9・19.0.10・18.11.13 で、いまの最新は 19.5.3 などです。
原因は GitLab 自体ではなく、Ruby の正規表現エンジン（Onigmo）のバグです。CI/CD の設定に書かれた正規表現をコンパイルするときにメモリが壊れ、そこからコード実行に持ち込めます。GitLab.com と GitLab Dedicated は修正済みで、対象は自社で運用している GitLab です。
手順は「版を確かめる → 証拠を残す → 最新のパッチ版へ更新 → 痕跡を調べる」の順です。更新で痕跡が消えるおそれがあるので、更新の前に、ログとバックアップを保全します。

社内の Git の置き場として GitLab を自分たちで運用している方向けの記事です。ニュースを見て「うちの GitLab は大丈夫か」と確かめたい人が、版の確認から更新、痕跡の調べ方までを一通りたどれるようにまとめました。

この記事は、GitLab のパッチリリースの告知（19.4.2 と 19.5.1、19.5.3）、CISA の KEV の掲載内容と BOD 26-04 の実施ガイダンス、Ruby の公式ニュース、NVD の記載（いずれも2026年10月30日に確認）をもとにしています。時点が動きやすい話題なので、上げ先の版は、必ず公式のリリース一覧で最新を確かめてください。

何が起きたのか：2つの重大な脆弱性と、KEV への追加

今回の話題は、似た名前の脆弱性が複数あって混乱しやすいので、先に時系列で整理します。

日付（2026年）	出来事	内容
10月12日	GitLab が 19.4.2・19.3.5・19.2.8 を公開	CVE-2026-97229（CVSS 10.0）を含む重大な修正。CI/CD の設定の正規表現の処理で整数があふれる問題
10月21日	GitLab が 19.5.1・19.4.3・19.3.6 ほかを公開	別の CVSS 10.0（CVE-2026-110264）の修正。対象の版がさらに広く、18.11 系や 7.0 以降の古い版まで範囲に入る
10月23日	Ruby が 4.0.9・3.4.12・3.3.13 を公開	根っこの正規表現エンジンのバグを修正。GitLab が付けた4つの CVE の元になった不具合
10月29日	CISA が CVE-2026-97229 を KEV に追加	対応の期限は11月1日。侵害の調査（フォレンジックのトリアージ）が必要な項目

GitLab の告知によると、CVE-2026-97229 は、特別に作った正規表現を CI/CD の設定に書くことで、認証されていないユーザーが GitLab のサーバー上で任意のコードを実行できる可能性がある問題です。深刻度は CVSS 10.0（ネットワークから、条件が易しく、権限も利用者の操作も要らない）とされています。

「修正版を入れたつもり」が一番危ない

10月12日の修正版（19.4.2 など）は、CVE-2026-97229 だけを直したものです。10月21日の告知で、同じ正規表現の処理に別の脆弱性（CVE-2026-110264）が直されており、19.4.2 の時点では残っています。「19.4.2 に上げたから済んだ」と判断せず、後述の上げ先の表で、最低ラインを満たしているか確かめてください。

KEV にあるのは CVE-2026-97229 で、2026年10月29日時点の KEV には CVE-2026-110264 は載っていません。ただし、どちらも同じ種類の問題で、10月21日以降の修正版にはどちらの修正も入っています。KEV に載っているかどうかで上げ先を分けず、最新のパッチ版へ上げるのが安全です。

なぜ「正規表現」でコード実行になるのか

Ruby の公式ニュースによると、GitLab は、利用者が入力した正規表現（CI の設定にあるパターンなど）を Regexp.new でコンパイルしています。GitLab が見つけたのは、細工したパターンをコンパイルさせると、Ruby の内部でメモリが壊れ、それをコード実行に持ち込めるという問題でした。

GitLab の側の対応

GitLab は、同梱している Ruby に独自の修正を当てて、自社のリリース（19.4.1・19.4.2・19.5.1）で直しました。GitLab を使う人は、Ruby の版ではなく GitLab の版を上げることになります。

Ruby の側の対応

根っこの不具合は、Ruby 4.0.9・3.4.12・3.3.13（2026年10月23日）で直りました。3.3 系は通常は脆弱性の修正だけの時期ですが、今回は例外として修正が入っています。

GitLab 以外の Ruby アプリは？

Ruby の告知では、攻撃者が決められる文字列から正規表現を作っているアプリだけが対象です。開発者が書いた正規表現だけを使うアプリは影響を受けません。Regexp.timeout や、パターンの長さの制限では防げないとも書かれています。

CISA の KEV の備考欄にも、「同じ Ruby/Onigmo の整数オーバーフローによって、ほかの製品が影響を受ける可能性がある」と書かれています。自社で作った Ruby / Rails のアプリが、利用者の入力から正規表現を組み立てていないかも、この機会に見直す価値があります（Ruby の更新も合わせて検討します）。

自分の GitLab は対象か：確かめる3点

対象かどうかは、次の3点で決まります。

確認すること	対象になる条件	確かめ方
運用の形	自社のサーバーなどで動かすセルフホスト版（GitLab.com と GitLab Dedicated は修正済み）	契約・構築の記録
GitLab の版	下の表の「最低ライン」より前の版	画面の Help、または `gitlab-rake gitlab:env:info`
到達できる範囲	インターネットや広い社内ネットワークから GitLab にアクセスできる	ファイアウォールとリバースプロキシの設定

GitLab の公式ドキュメントによると、版は、サインインした状態で左のサイドバーの下にある Help から開く Help のページの先頭に表示されます。サーバーに入れる場合は、公式のドキュメントにある次のコマンドでも確かめられます（Linux パッケージで入れた場合）。

# 版を含む環境情報を表示する（Linux パッケージ版）
sudo gitlab-rake gitlab:env:info

そのうえで、現在の版と、次の「最低ライン」を見比べます。同じ系列（19.4 など）の中で、最低ラインより小さければ、対象です。

使っている系列	CVE-2026-97229 の修正版	CVE-2026-110264 の修正版（最低ライン）	10月29日以降のパッチ版
19.5	（97229 の対象に書かれていない）	19.5.1	19.5.3
19.4	19.4.2	19.4.3	19.4.5
19.3	19.3.5	19.3.6	19.3.7
19.2	19.2.8	19.2.9	19.2.10
19.1	（97229 の対象に書かれていない）	19.1.9	19.1.10
19.0	（97229 の対象に書かれていない）	19.0.10	19.0.11
18.11	（97229 の対象に書かれていない）	18.11.13	18.11.14
18.10 以前	（97229 の対象に書かれていない）	7.0 以降のすべての版が対象。修正版は上の系列にしか無い	上の系列へ更新

表の「10月29日以降のパッチ版」は、GitLab が公開した 19.5.3 ほかの告知に基づきます。その後にも新しい版が出ている可能性があるので、更新する直前に、GitLab のリリース一覧で最新のパッチ版を確かめてください。

更新の手順：証拠を残してから、最新のパッチ版へ

更新そのものは、公式の手順どおりに進めます。注意するのは順序です。CISA の実施ガイダンスは、悪用が確認された脆弱性への対応で、可能なら、システムに手を入れる前に証拠を集め、そのあとでパッチを当てるように求めています。パッチや再起動で、メモリ上の情報やログが失われるおそれがあるためです。

更新から痕跡の確認までの流れ

1
版と公開範囲を確かめる
Help のページか gitlab-rake gitlab:env:info で版を確認する。インターネットから GitLab に直接届くか、VPN の中だけかも、このとき確かめる。
2
ログとバックアップを保全する
GitLab のログ（production_json.log、nginx のアクセスログ、Sidekiq のログなど）と、サーバーのスナップショットや公式の手順によるバックアップを、更新の前に別の場所へ退避する。
3
アップグレードパスを確かめて更新する
公式のアップグレードパスで、必須の中継バージョン（19.2、19.5 など）を確認する。同じ系列の最新のパッチ版へ上げるのが基本。Linux パッケージなら apt や yum で上げ先を指定する。
4
Runner など周辺も更新する
GitLab 本体を上げても、自社運用の GitLab Runner や AI Gateway は自動では上がらない。19.5.3 の告知でも、別に更新するよう求めている。
5
痕跡を調べ、疑わしければ切り離す
更新後も、10月12日より前から公開していた場合は、ログに異常が無いかを調べる。疑わしい兆候があれば、サーバーを切り離し、情報システム部門や専門家に相談する。

Linux パッケージ版（Ubuntu / Debian）の場合、GitLab の公式ドキュメントは、次のような形で上げ先を指定します（<version> には上げ先の版を入れます）。

# Enterprise Edition を、指定した版へ更新する
sudo apt update && sudo apt install gitlab-ee=<version>-ee.0

# Community Edition を、指定した版へ更新する
sudo apt update && sudo apt install gitlab-ce=<version>-ce.0

必須の中継バージョンは、GitLab 19 では 19.2・19.5・19.8・19.11 と公式に書かれています。たとえば 19.4 系から 19.5 系へ上げるなら中継は不要ですが、18.x から 19 系へ上げるときは、途中の中継版を順に通る必要があります。詳細は、必ず公式の「Plan your upgrade path」で確かめます。

更新後の注意として、19.5.3 の告知は、GitLab 本体を上げても、自社で動かしている GitLab Runner と AI Gateway は自動では上がらないことを案内しています。この告知は、GitLab が信頼する証明書の一部を外した件（CVE-2026-111943）ですが、Runner を自社で運用している人は、このタイミングで一緒に確認するとよいでしょう（Runner）。

侵害されていないかを確かめる：CISA の考え方

KEV の CVE-2026-97229 の欄には、「フォレンジックのトリアージ（侵害調査）が必要」という印が付いています。つまり、更新して終わりではなく、更新の前に悪用されていないかを調べることが求められています。

CISA の BOD 26-04 の実施ガイダンスは、米国の連邦機関向けの手引きです。日本の企業に義務があるわけではありませんが、考え方の参考にはなります。主な流れは次のとおりです。

1. 範囲を決める

どのサーバーが対象か、外から届くのはどれかを洗い出す。調査の連絡には、侵害されているかもしれない社内のチャットやメールに頼らない連絡手段を用意する。

2. 証拠を残す

消えやすいメモリ上の情報から先に集め、ログやディスクの内容も集める。可能なら、システムを書き換える前に行い、集めたものを記録に残す。

3. パッチと隔離

証拠を集めたあとに、パッチを当てる。侵害が疑われるものは、攻撃者に気づかれない形で切り離す。急いで切り離すと証拠を壊すことがある。

4. 調べて判断する

不正なアクセス、攻撃者の存在、内部への横展開、居座るための仕掛け、データの持ち出しが無いかを調べ、専門家への相談など次の対応を判断する。

GitLab が出している検知の名前

GitLab のパッチ告知には、自社運用のインスタンス向けに、CVE-2026-97229 では6つ、CVE-2026-110264 では2つの「検知」が示されています。名前は次のとおりです（告知の記載のままです）。

対象	検知の名前
CVE-2026-97229	Onigmo native worker crash／Graphql cilint hostile regexp／ci regexp oversized non ascii path／ci regexp guard rejection／ci lint workhorse worker crash／ci lint scripted client error burst
CVE-2026-110264	Onigmo native worker crash／Org mode render error burst

名前からは、正規表現の処理でワーカーが異常終了していないか、CI の文法チェック（CI lint）の API に異常なリクエストが短時間に集中していないかといった観点だと読めます（この読みは筆者の推測で、公式が個々の内容を詳しく書いているわけではありません）。実際に何をどのログで調べるかは、GitLab のパッチ告知の該当の節で確かめてください。

痕跡が無いことは、侵害されていない証拠にならない

ログが十分に残っていない、更新前に再起動してしまった、といった理由で、調べられない範囲が出ます。GitLab のリポジトリには、ソースコードや CI の秘密情報（トークンや鍵）が入っています。疑わしい兆候があれば、アクセストークン・デプロイキー・CI/CD の変数の再発行まで視野に入れ、必要なら専門家に相談します。

すぐに更新できないとき

私が確認した GitLab のパッチ告知（19.4.2 と 19.5.1）には、更新以外の回避策は書かれていません。以降は公式の指示ではなく、この記事の筆者の考えです。

到達できる範囲を狭める

今回の問題は「認証なしで、ネットワークから」届くのが危険の核心です。インターネットに公開している GitLab なら、VPN の内側に移す、接続元の IP アドレスを限定するといった入口を絞る対応が、更新までのつなぎとして考えられます。

つなぎは更新の代わりにならない

入口を絞っても、社内ネットワークに入られた場合や、設定の漏れがあれば防げません。更新の計画は止めず、できるだけ早く最新のパッチ版へ上げてください。

更新の時間が取れない場合の最後の手段として、GitLab をいったん止める判断もありえます。止めたときの影響（デプロイ、レビュー、CI）と、止めずに使い続けるリスクを並べて、責任者と決めます。

今回の学び：自社運用の開発基盤は「更新の運用」が要

今回、修正版は10月12日に出ていて、KEV への追加は10月29日です。17日のあいだに更新していた人は、悪用の期限に追われずに済みました。

パッチ版は毎月上げる

GitLab は、定期のパッチ版を月に2回（第2・第4水曜日）出すと告知で説明しています。重大な脆弱性は、臨時のパッチとして出ます。月に1回の定期更新の枠を決めておくと、慌てずに済みます。

公開範囲を最小に

社内の開発基盤は、インターネットに直接出さず、VPN や IP アドレスの制限の内側に置くのが基本です。今回のような「認証なしで届く」問題でも、到達できなければ悪用されません。

シークレットを置きすぎない

CI の変数やリポジトリに、本番の鍵やトークンを置くほど、侵害された場合の被害が広がります。短い期限で失効する認証情報を使うなど、置き方を見直します。

情報を拾う仕組みを持つ

KEV や JPCERT/CC の発表を定期的に確かめる運用にしておくと、今回のようなニュースを見逃しません。詳しくは脆弱性情報の集め方を参照してください。

KEV の使い方や優先度の付け方は KEVカタログとは？、CI/CD の基本は GitHub Actions 入門も参考にしてください。

よくある質問

GitLab.com を使っているだけなら、何かすべきですか？

GitLab の告知によると、GitLab.com と GitLab Dedicated は修正済みのバージョンで動いていて、利用者が更新する必要はありません。対象は、自社のサーバーなどで運用するセルフホスト版です。

19.4.2 に上げたので、もう大丈夫ですか？

CVE-2026-97229 については修正済みですが、CVE-2026-110264（10月21日に修正）は、19.4.3 以降で直ります。19.4 系なら 19.4.3 以降、できれば最新のパッチ版まで上げてください。

悪用は確認されていますか？

CISA は、CVE-2026-97229 を KEV に追加しており、「悪用が確認された」と整理しています。ランサムウェアの攻撃での利用が確認されているかは、KEV の項目では「不明」とされています（2026年10月30日時点）。

CE（Community Edition）も対象ですか？

はい。告知の対象は「GitLab CE/EE」で、無償の Community Edition も含みます。

自社運用の Ruby アプリも危険ですか？

利用者の入力から正規表現を作っているアプリだけが対象になります。Ruby の公式ニュースは、4.0.9・3.4.12・3.3.13 以降への更新を勧めています。更新できないときは、攻撃者が決められる文字列から正規表現をコンパイルしないようにする、としています。

まとめ

自社運用の GitLab に、認証なしでコード実行を受けうる脆弱性（CVE-2026-97229、CVSS 10.0）。2026年10月29日に KEV に追加され、期限は11月1日、侵害調査も求められる
10月12日の修正版（19.4.2 など）では足りない。10月21日に別の CVSS 10.0（CVE-2026-110264）が修正されており、最低ラインは 19.5.1・19.4.3・19.3.6・19.2.9・19.1.9・19.0.10・18.11.13。最新は 19.5.3 など
原因は Ruby の正規表現エンジンのバグ。GitLab.com と GitLab Dedicated は修正済みで、対象はセルフホスト版
手順は「版の確認 → ログとバックアップの保全 → 最新のパッチ版へ更新 → Runner など周辺の更新 → 痕跡の確認」
更新できないときは、公開範囲を絞る（筆者の考え）。ただし更新の代わりにはならない

GitLab の重大な脆弱性（CVE-2026-97229・CVE-2026-110264）とは？自社運用の確認と更新手順