GitLab 脆弱性の悪用を確認｜更新しても直らなかった理由はRubyにある

何が起きたのか？

2026年9月から10月にかけて、GitLab は正規表現の処理に起因する深刻な脆弱性を4件公表しました^[1][2][3]。そのうち10月12日に修正した CVE-2026-97229 は、公開から約1週間後に Alpine Linux の GitLab への攻撃に使われ^[5][13]、10月29日には米CISA が KEV に追加して米連邦機関に11月1日までの対応を求めました^[7]。国内でも Security NEXT が、KEV への追加と、根本原因が Ruby にあることを報じています^[10][11]。

1. 9月23日

   GitLab が正規表現の脆弱性2件を修正

   19.4.1 / 19.3.3 / 19.2.7 で CVE-2026-89078 と CVE-2026-93577 を修正。いずれも CVSS 9.9 で、認証済みユーザーが条件^[3]。

2. 10月12日

   CVE-2026-97229 の修正版を公開

   19.4.2 / 19.3.5 / 19.2.8 を公開。認証なしでコード実行のおそれ、CVSS 10.0^[1]。

3. 10月13日

   CVE が公開され、Rapid7 が再現

   NVD に CVE が登録される^[14]。セキュリティ企業 Rapid7 が未修正版でコード実行を再現し、通常の更新サイクルを待たずに更新するよう呼びかけた^[9]。Alpine Linux は同日、修正を含む 19.3.5 ではなく 19.3.4 へ誤って更新^[5]。

4. 10月20〜21日

   Alpine Linux の GitLab が攻撃を受ける

   新規登録されたアカウントが細工した CI 設定を送信。ワーカープロセスが8回クラッシュし、502 エラーや CI ジョブの失敗が発生^[5]。

5. 10月21日

   GitLab が CVE-2026-110264 を修正

   19.5.1 / 19.4.3 / 19.3.6 / 19.2.9 と、旧系列の 19.1.9 / 19.0.10 / 18.11.13 を公開。7.0 以降のすべての版が対象で CVSS 10.0^[2]。

6. 10月22〜23日

   Alpine が 19.3.6 へ更新、Ruby が修正版を公開

   22日の GitLab 更新では脆弱性が直らず^[5]。23日に Ruby 開発チームが 4.0.9 / 3.4.12 / 3.3.13 を公開^[4]。Alpine は同日、攻撃者のアカウントを遮断^[5]。

7. 10月26〜28日

   Alpine が「まだ脆弱」と判明し、再構築

   26日に更新後も脆弱なままと判明。27日に開発者とビルドサーバー以外への GitLab の提供を止めて再構築を開始し、28日に完了。全パスワードをリセットし秘密鍵を交換、経緯を公表^[5]。

8. 10月28日

   JPCERT/CC が Weekly Report で紹介

   「GitLabに複数の脆弱性」として、10月21日の修正版への更新を案内^[8]。

9. 10月29日

   CISA が KEV に追加、Alpine が再開

   米連邦機関の対応期限は11月1日^[7]。Alpine は 19.3.7 と修正済みの Ruby 3.3.13 で GitLab を再開^[5][6]。

KEV は、米CISA が「実際に悪用が確認された」と判断した脆弱性だけを載せる一覧です。載ったということは、机上の危険ではなく、攻撃者がすでに使っているということです^[7]。GitLab.com（GitLab 社が運営するクラウド版）は修正済みで、対応が必要なのは自社のサーバーで動かす自己管理版です^[1]。

CVE-2026-97229 はどのような脆弱性か？

CI/CD の設定ファイルに書かれた正規表現を GitLab が処理する際、細工された正規表現によって整数オーバーフロー（数値が扱える範囲を超えて壊れる不具合）が起き、認証なしでサーバー上の任意のコードを実行されるおそれがある脆弱性です^[1][14]。GitLab は、正規表現の検証が不十分だったことが原因だと説明しています^[1]。

正規表現は「特定のパターンに合う文字列を探す」ための記法で、GitLab では CI/CD の設定でブランチ名やファイルパスの条件を書くときなどに使われます。GitLab は利用者が書いたこのパターンを Ruby の機能でコンパイル（実行できる形に変換）しており、その変換処理に不具合がありました^[4]。

Rapid7 は、未修正の公式 GitLab CE 19.4.1 のイメージでコード実行を再現し、修正版 19.4.2 では同じ入力が実行されないことを確認しています^[9]。実行されるコードの権限は、GitLab の git ユーザーです^[9]。あわせて Rapid7 は、攻撃者は事前に悪意ある CI/CD 設定をリポジトリに置く手段が必要で、新規ユーザーが自分でアカウントを登録してプロジェクトを作れる設定のサーバーでは、この制約がなくなると指摘しています^[9]。Alpine Linux を攻撃したのも、新しく登録されたアカウントでした^[5]。

4件はいずれも同じ報告者（joaxcar）が GitLab のバグ報奨金プログラムを通じて報告したものです^[1][2][3]。GitLab は自己管理版の利用者向けに、悪用の試みを見つけるための検知ルールも公開しています^[1][2]。10月21日の CVE-2026-110264 は影響範囲が 7.0 以降のすべての版に及ぶため、GitLab は通常の修正版に加えて 18.11.13・19.0.10・19.1.9・19.2.9 にも修正を移植しました^[2]。

なぜ GitLab を更新しても直らなかったのか？

修正の中身が GitLab のプログラムではなく、GitLab が内部で使う Ruby へのパッチだったからです^[4][5]。GitLab の公式パッケージや公式コンテナイメージには修正済みの Ruby が同梱されていますが、Alpine Linux は自分たちで作ったイメージで標準の Ruby を使っていたため、GitLab 本体を更新しても Ruby は古いままでした^[5]。

Alpine Linux は、Docker などのコンテナイメージの土台として広く使われている Linux ディストリビューションです^[16]。その開発基盤である GitLab には、パッケージの作り方を定めた aports のリポジトリや CI ジョブが置かれており^[5]、改ざんされれば下流のソフトウェアに影響が及ぶ、サプライチェーン上の重要な標的でした^[16]。

Alpine Linux の公表によると、10月20日に新規登録されたアカウントが探索を始め、20〜21日にかけて細工した CI 設定を送り込み、ワーカープロセスを合わせて8回クラッシュさせました（主な攻撃は21日）。4回は攻撃が途中まで進んで次の段階で失敗しており、攻撃者は Alpine の GitLab コンテナイメージも取得していました。Alpine は、攻撃者が自分たちの環境に合わせて攻撃を調整していたことを示すと見ています^[5]。

Alpine は、攻撃が成功した証拠は見つからなかったものの、否定もできないとして、GitLab を侵害されたものとみなして一から再構築しました^[5]。断定できない理由として、成功していればクラッシュも Web のログも残らないこと、攻撃当日の一部のログが消えていたこと、サーバーからの外向き通信を記録していなかったことを挙げています^[5]。

再構築後の GitLab は10月29日に 19.3.7 と修正済みの Ruby 3.3.13 で再開し、30日に利用者向けの案内が公表されました^[5][6]。秘密鍵を交換したため、全利用者のパスワード・2要素認証・アクセストークンは無効になり、CI/CD 変数の値も空になっています^[6]。パッケージやリリースに改ざんはなく、パッケージに署名する鍵は GitLab サーバーに置かれたことがないとしています^[5]。

GitLab を使っていなくても関係があるのか？

あります。不具合は Ruby の正規表現エンジンにあるため、利用者や外部から受け取った文字列をもとに正規表現を組み立てる Ruby 製のアプリケーションは、GitLab でなくても同じ影響を受けます^[4]。米CISA も KEV の注記で「同じ Ruby/Onigmo の問題で他の製品も影響を受ける可能性がある」と明記しています^[7]。

Ruby 開発チームの説明では、影響を受けるのは、攻撃者が制御できる文字列から正規表現をコンパイルするアプリケーションに限られます。具体的には Regexp.new・Regexp.union・Regexp.compile に外部の文字列を渡す場合や、正規表現リテラルに外部の文字列を埋め込む場合です。開発者自身が書いた正規表現だけを使うアプリケーションは影響を受けません^[4]。

対策は Ruby 4.0.9・3.4.12・3.3.13 以降への更新です^[4]。Ruby 3.3 系は通常はセキュリティ修正しか出ない保守段階ですが、今回は例外として修正が取り込まれました^[4]。更新できない場合は、信頼できない入力から正規表現を作らないことが Ruby 開発チームの推奨です^[4]。

注意したいのは、Ruby 開発チームが今回の修正に Ruby 側の CVE 番号を要求していないことです。追跡には GitLab の CVE 番号を使うよう案内しています^[4]。脆弱性スキャナーや脆弱性情報の配信サービスで「Ruby」の脆弱性として検索しても出てこない可能性があり、GitLab の CVE 番号で探すか、Ruby の版そのものを確認する必要があります^[4]。

Ruby は、まつもとゆきひろ氏が設計したプログラミング言語です^[15]。自社で Ruby を書いていなくても、外注した業務システムや利用中の Web サービスが Ruby で動いている場合があります。「うちは GitLab を使っていない」で終わらせず、Ruby 製のシステムが社内や取引先にないかまで見る必要があります。

自社への影響をどう判断するか？

判断の軸は2つです。1つは、自社の GitLab が「公式パッケージ・公式コンテナ」か「独自に Ruby を組み込んだ構成」か。もう1つは、自社に関わる Ruby 製のシステムが「外部から受け取った文字列で正規表現を作っている」かです^[4][5]。

最後の行が最も多いはずです。GitLab や Ruby は自社の社員が触らなくても、開発会社の環境や納品されたシステムの中で動いています。「うちは GitLab を使っていない」と即答できる企業ほど、外注先に確認する価値があります。

GitLab のサーバーが乗っ取られた場合に失われるものは、ソースコードだけではありません。Alpine Linux が「成功していれば漏えいし得た」として挙げた項目には、CI/CD 変数、ランナーのトークン、Webhook や外部連携の認証情報が含まれます^[5]。CI/CD 変数にはデプロイ先のパスワードやクラウドの鍵が入っていることが多く、開発基盤の侵害は、そこから本番環境やクラウドへ広がる入口になります。

今すぐやることは何か？

今週中に、自社と外注先の GitLab の版と Ruby の版を確認し、該当すれば更新してください。あわせて、新規ユーザーの自己登録と公開プロジェクトの設定、そして Ruby 製システムで外部入力から正規表現を作っていないかを確認します^{[1][2][4][5][9]}。

更新中は GitLab が一時的に止まることがあります。構成によっては無停止で更新する手順もあるため、手順を確認したうえで利用の少ない時間帯に実施し、更新後に CI/CD のパイプラインが正常に動くことを確認してください。Alpine Linux のように再構築まで踏み込むかどうかは、ログで攻撃の有無を判断できるかで決まります。ログが残っていなければ、「証拠がない」は「安全」を意味しません^[5]。更新を先送りしたときに何が起きるかは、PHP2Shell の解説記事でも整理しています。

中長期で何を見直すべきか？

中長期の課題は、ソフトウェアを「製品名」ではなく「中に入っている部品」の単位で把握することです。今回のように、脆弱性が製品名で公表されながら実際の不具合が中の部品にある場合、製品だけを見ていると更新の抜けが起きます^[4][5][7]。

• 部品まで書いた台帳を持つ：サーバーやツールごとに、本体の版だけでなく、言語ランタイム（Ruby・PHP・Node.js など）やライブラリの版を記録する。Alpine Linux も再発防止策として、各リリースで Ruby などの部品のパッチを自分たちのビルドに当てる必要があるかを毎回確認することを挙げています^[5]
• 公式の配布物を優先する：独自ビルドや独自コンテナは、修正の同梱に自分で追随する責任が生じます。独自構成を選ぶなら、その理由と追随の担当者を決める
• 重大な修正は日数を決めて適用する：Alpine は重大な GitLab のセキュリティリリースを1日以内に適用することにしました^[5]。自社でも「CVSS 9 以上は何営業日以内」のように基準を決める
• ログを残す：Alpine は再発防止策として、GitLab サーバーからの外向き通信とデータベース接続の記録、14日より長いログの保持を挙げています^[5]。認証のログもあわせて残す。Alpine が攻撃の成否を断定できなかった理由の一つは、外向き通信のログがなかったことです^[5]
• 開発基盤の認証情報を定期的に入れ替える：CI/CD 変数やトークンは、漏えいしても期限で無効になるよう、短い有効期限と定期的な更新を習慣にする
• 外注先との契約に版の報告を入れる：納品物や保守対象について、使用している言語ランタイム・フレームワーク・主要ライブラリの版と更新方針を報告してもらう

AI利用の観点で見直す点はあるか？

あります。まず、GitLab のような開発基盤に AI 機能が組み込まれ、そこにも脆弱性が出ていることです。次に、AI コーディングツールが部品を自動で増やすため、「中に何が入っているか」を人が把握しにくくなっていることです。

10月12日の修正版には、GitLab の AI 機能「GitLab Duo Agent Platform」で、認証済みユーザーが細工した内容を AI エージェントへの指示に混ぜ込み、他のユーザーに帰属する形で意図しないコマンドが実行されるおそれのある脆弱性（CVE-2026-96893、CVSS 7.3、Enterprise Edition が対象）の修正も含まれています^[1]。AI エージェントへの指示に外部の文字列が混ざる問題は、AI コーディングエージェントの指示ファイル乗っ取りの記事で扱った構図と同じです。

また、Claude Code や Codex のような AI コーディングツールは、作業の途中でライブラリや言語ランタイムを自動で追加・更新することがあります。人が選んでいない部品が環境に入るため、部品の台帳がないと、今回のような「部品の脆弱性」に気づく手段がありません。AI を使う人が増えるほど、台帳の必要性は高まります。AI 利用に伴うリスクの全体像はAIセキュリティとはで整理しています。

まとめ

GitLab の CVE-2026-97229 は、2026年10月29日に米CISA が悪用を確認した CVSS 10.0 の脆弱性です^[1][7]。根本原因は Ruby の正規表現エンジン Onigmo にあり、Alpine Linux は GitLab を更新しても、独自に組み込んだ Ruby が古いままだったため脆弱性が残っていました^[4][5]。

今週やることは、自社と外注先の GitLab の版と Ruby の版を確認して該当すれば更新すること、自己登録の設定を見直すこと、Ruby 製システムで外部入力から正規表現を作っていないかを確認することです。そのうえで、製品名ではなく部品の単位で環境を把握する台帳を作ることが、次に同じ構図の脆弱性が出たときの備えになります。よくある質問はFAQもあわせてご覧ください。