修正版が出てから17日で、GitLabのCI/CDの脆弱性は「悪用あり」に変わりました。米国のCISAは10月29日、GitLab CE・EEのCVE-2026-97229を、悪用が確認された脆弱性の一覧（KEV）に加えました。CI/CDの設定に細工した正規表現を入れると、ログインしていない攻撃者がGitLabのサーバーでコードを実行できるという脆弱性で、深刻度はCVSS 3.1で最大の10.0です。
KEVの記載では、米国の連邦機関の期限は11月1日です。修正版を当てる前に侵害されていなかったかを調べる「侵害の調査」も、あわせて求められています。社内でGitLabを動かしている会社は、版を確かめるだけでなく、10月半ばからの記録を残して見直す段階に入りました。
CISAの10月29日の発表。GitLabとCiscoの2件をKEVに追加出典: CISA「CISA Adds Two Known Exploited Vulnerabilities to Catalog」(引用)
修正から17日で「悪用あり」に
この脆弱性は、10月12日のGitLabの緊急の修正版で直りました。その翌日には、セキュリティ会社のRapid7が、修正前のGitLabでコードの実行を再現したと公表しています。
| 日付 |
できごと |
| 10月12日 |
GitLabが19.4.2、19.3.5、19.2.8を公開 |
| 10月13日 |
Rapid7が、修正前の19.4.1でコードの実行を再現したと公表 |
| 10月20〜21日 |
Alpine LinuxのGitLabが攻撃を受け、ワーカーが8回落ちる（10月28日の公表） |
| 10月23日 |
Rubyが正規表現の修正を入れた4.0.9、3.4.12、3.3.13を公開 |
| 10月29日 |
CISAがKEVに追加 |
| 11月1日 |
米国の連邦機関の期限 |
経緯の前半は、GitLabが重大脆弱性を修正、自社管理環境は即時更新を確認にまとめています。Alpine Linuxの件とRubyの修正は、Rubyの正規表現の脆弱性、GitLabに攻撃の試み 自前のRubyは4.0.9などへにあります。CISAは、どこで誰が悪用したのかを書いていません。KEVの記載では、ランサムウェアでの利用は「不明」です。
期限は3日、侵害の調査つき
KEVへの追加から期限までは3日です。米国の連邦機関には、CISAの指令（BOD 26-04）の手引きに沿って、パッチの前に証拠を残し、侵害されていなかったかを調べることも求めています。調べる順番は、前日のKEVの記事の表にまとめた6段階と同じです（Linuxの「Fragnesia」とESXの脆弱性がKEVに 米機関の期限は3日と14日）。
KEVは、同じ根の問題がほかの製品にもありうると注記しています。CI/CDの正規表現の処理に使われる、RubyのOnigmoの整数のあふれです。
同じ10月29日には、CiscoのASA・FTDの脆弱性もKEVに入りました。リモートアクセスVPNで機器を再起動させられるもの（CVE-2026-76418）です。こちらも期限は11月1日ですが、侵害の調査は求められていません。中身はCisco ASAとFTDのVPNに悪用中の脆弱性 二次認証の設定で再起動させられるにあります。
直ったかどうかは、版の末尾とRubyで見る
GitLabの告知の対象の版は、下の表のとおりです。19.3系では、19.3.4は修正の入る前の版で、19.3.5に差し替わっています。10月21日には、さらに次の緊急の修正版も出ているので、上げるなら使っている系列の最新版にします。
GitLabの告知のCVE-2026-97229の節と、6つの検知出典: GitLab「GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8」(引用)
もう1つの落とし穴は、Rubyです。この脆弱性の修正は、GitLabが公式のパッケージに同梱するRubyへの手直しでした。ソースから作ったGitLabや、自前のコンテナのイメージで標準のRubyを使っている場合は、GitLabを上げても直りません。Rubyも、表の修正版以降が要ります。Alpine Linuxは、まさにこの理由で、GitLabを上げたあとも脆弱なままでした。
| 確かめるもの |
足りている状態 |
| GitLab 19.4系 |
19.4.2以降（できれば最新版） |
| GitLab 19.3系 |
19.3.5以降。19.3.4は不可 |
| GitLab 19.2系 |
19.2.8以降 |
| 自前のRubyで動かす場合のRuby |
3.3.13、3.4.12、4.0.9以降 |
| GitLab.com・GitLab Dedicated |
GitLabが修正済みとしている |
GitLabが出した6つの検知
GitLabは告知の中で、セルフマネージドの利用者向けに、悪用の試みを見つけるための検知を6つ公開しています。名前から読み取れる中身は次のとおりです。検知の本文はGitLab.comの公開のリポジトリにあります。
| 検知の名前 |
名前が示すもの |
| Onigmo native worker crash |
Onigmoの処理の途中で、ワーカーのプロセスが落ちる |
| Graphql cilint hostile regexp |
GraphQLのCI Lint（CIの設定の検査）に、悪意のある正規表現が送られる |
| ci regexp oversized non ascii path |
CIの設定の正規表現に、異常に長い非ASCIIの文字列が入る |
| ci regexp guard rejection |
正規表現の防御の処理が、要求を断った |
| ci lint workhorse worker crash |
CI Lintの要求のあとに、Workhorseのワーカーが落ちる |
| ci lint scripted client error burst |
スクリプトのような送り手から、CI Lintのエラーが続けて返る |
Alpine LinuxのGitLabでは、新しく作られたアカウントが細工したCIの設定を送り、ワーカーが8回落ちていました。上の1つ目や5つ目に当たる形です。Alpineは、成功した攻撃は落ちた跡もWebのログも残さないとして、跡が無いことを侵害が無かった証拠にはしていません。
影響するのは、自社で動かすGitLab
対象は、自社のサーバーやクラウドで動かすセルフマネージドのGitLab CE・EEです。インターネットから届くGitLabほど急ぎます。社内のネットワークだけで使っていても、取引先や委託先が入れる、社員の端末からVPNで届く、という形なら、攻撃者が中に入った後の足場になりえます。
GitLab.comとGitLab Dedicatedは、GitLabが修正済みとしています。GitLab Runnerだけを社内で動かしている場合は、GitLabの本体が対象で、Runnerの更新はこの件の告知に含まれていません。
11月1日までに進める手順
- 社内のGitLabを一覧にし、版、Rubyを同梱した公式のパッケージかどうか、インターネットから届くかを書き出します。委託先が運用しているGitLabも含めます。
- 版が足りないもの、または自前のRubyが古いものは、更新や作り直しの前に記録を残します。写す先は、GitLabの外の場所です。GitLabの記録の手引きにある主な記録（注）を、10月13日以降の分だけでも写しておきます。
- 写した記録で、ワーカーの異常な終了、CI Lintへの続けざまの要求、10月中旬以降に作られた見慣れないアカウントを探します。GitLabの6つの検知を、監視の仕組みに入れられるか、監視の担当に相談します。
- 修正版に上げます。自前のRubyで動かしているなら、Rubyも3.3.13、3.4.12、4.0.9以降にします。
- 跡が見つかった、または記録が残っていなくて否定できないときは、乗っ取られたものとして扱います。Runnerのトークン、CI/CDの変数、デプロイの鍵、外部の連携のトークン、利用者のパスワードと2要素認証の設定を替える計画を立てます。
最後の判断が、いちばん重い作業です。Alpine Linuxは、記録が足りずに侵害を否定できなかったため、GitLabを一から作り直しました。社内のGitLabでも、記録を何日分、どこに残しているかで、取れる選択肢が変わります。
注: GitLabの記録の手引きにある主な記録です。Railsの記録（production_json.log、api_json.log、auth_json.log、exceptions_json.log）、Pumaの記録（puma_stderr.log）、Sidekiqとgitlab-workhorseの記録を写します。
