CVE-2026-97229 GitLab｜攻撃試行と独自ビルドの修正確認

はじめに

2026年10月28日、Alpine Linux は自組織の GitLab に対して、CVE-2026-97229 を悪用する攻撃試行があったと公表しました。注目すべき点は、Alpine Linux が GitLab 19.3.6 へ更新した後も、独自に用意した Ruby に修正が含まれず、脆弱性が残っていたことです。

GitLab の脆弱性対応では、製品のバージョン番号で修正済みかを判断するのが一般的です。しかし、ソースから構築した環境や独自の Ruby を使うコンテナーでは、その判断が成り立たない場合があります。

結論として、GitLab 公式の Linux パッケージやコンテナーイメージを使っている場合は、19.2.8 / 19.3.5 / 19.4.2 以降への更新で CVE-2026-97229 の修正が入ります。一方、ソースから構築した環境や独自の Ruby を使うコンテナーでは、GitLab の更新に加えて、修正済みの Ruby（4.0.9 / 3.4.12 / 3.3.13 以降、または同等のパッチ適用版）が実際に稼働していることを確認する必要があります。修正前に外部から到達可能だった場合は、更新とは別に攻撃痕跡の調査も検討してください。

CVE-2026-97229 と Alpine Linux への攻撃試行

CVE-2026-97229 は、CI/CD 設定内の正規表現の処理に起因する GitLab の脆弱性です。Alpine Linux は修正版の公開から約 1 週間後に攻撃試行を受け、侵害の可能性を否定できないとして GitLab を再構築しました。

CVE-2026-97229 の概要と修正版

GitLab は 2026年10月12日に 19.4.2 / 19.3.5 / 19.2.8 を公開し、この脆弱性を修正しました。CVSS v3.1 のスコアは 10.0 です。影響を受けるのは GitLab CE / EE の 19.2.8 未満の 19.2 系、19.3.5 未満の 19.3 系、19.4.2 未満の 19.4 系で、GitLab.com と GitLab Dedicated はリリース公開前に対応済みとされています。

これらは CVE-2026-97229 の初回の修正版です。その後、別のセキュリティ修正を含む 19.5.3 / 19.4.5 / 19.3.7 などの後続リリースも公開されているため、更新先は利用中の保守対象系列の最新パッチリリースを確認してください。

参考: GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
“could have allowed an unauthenticated user to execute arbitrary code”
（認証されていないユーザーが任意のコードを実行できた可能性がある）
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/

米国 CISA は 2026年10月29日に本脆弱性を KEV カタログへ追加しました。BOD 26-04 の対象となる米国の連邦政府機関向けの対応期限は 11月1日で、フォレンジックトリアージの対象ともされています。なお、KEV への登録は、Alpine Linux の環境で攻撃者による任意コード実行が成功したことを示すものではありません。

なお、二次情報の中には 19.3 系の修正版を 19.3.4 と記載したものがあります。GitLab の現在のリリースページでは、19.3 系は 19.3.5 未満が影響を受けると記載されているため、修正版は公式ページで確認してください。

Alpine Linux で確認された攻撃試行の時系列

Alpine Linux のインシデント報告（10月28日公開、10月30日更新）に基づき、主な経緯を整理します。

10月20〜21日の攻撃では、ワーカープロセスが 8 回クラッシュし、そのうち 4 回は攻撃手順が途中まで進んだ後、次の段階で失敗したと報告されています。攻撃者は Alpine Linux の GitLab コンテナーイメージもダウンロードしており、Alpine Linux は対象のビルドに合わせて攻撃を調整していた可能性を指摘しています。

確認された事実と否定できない範囲

Alpine Linux は、攻撃が成功した証拠は見つかっていないとしながらも、成功の可能性を否定できないと説明しています。

参考: Alpine Linux（GitLab security incident: attempted exploitation of CVE-2026-97229）
“We have found no evidence that it succeeded, but we cannot rule it out”
（攻撃が成功した証拠は見つかっていないが、その可能性を否定することはできない）
https://alpinelinux.org/posts/GitLab-security-incident-CVE-2026-97229.html

確認できた事項

タイミング計測で遅延は見られず、想定外のファイル、鍵、フック、プロセスも見つかっていません。確認できる範囲の Web / API リクエストで、非公開データが攻撃者に返された形跡もないとされています。

否定できない理由

攻撃が成功した場合は、クラッシュも Web ログの痕跡も残りません。また、攻撃当日のバックグラウンドジョブのログや旧コンテナーのファイルシステムが失われており、外向き通信のログもありませんでした。

成功した場合に露出し得た情報

利用者のメールアドレス・氏名・IP アドレス、パスワードハッシュ、2FA シークレット、CI/CD 変数、Runner トークン、Webhook や連携機能の認証情報、非公開リポジトリなどが挙げられています。

攻撃試行は確認されている一方、攻撃者による任意コード実行の成功は確認されていません。Alpine Linux は、成功の有無を判断するための証拠が残っていないことから、インスタンスを侵害されたものとして扱い、ゼロから再構築する方針を選びました。

Alpine Linux のパッケージへの影響

Alpine Linux は、aports、パッケージ、10月21日の安定版リリースを GitLab 外の記録と照合し、改ざんの形跡はなかったと報告しています。署名鍵も GitLab サーバーには保管されていなかったとのことです。ただし、照合の対象は 10月24日時点の範囲（10月20〜22日のコミットと 10月24日までのパッケージ）で、10月27日までの範囲へ拡大中とされています。Alpine Linux の利用者は続報を確認してください。

GitLab の更新後も脆弱性が残った理由

原因は、CVE-2026-97229 の修正が GitLab 本体のコードではなく、GitLab が同梱する Ruby へのパッチとして提供されていたことです。Alpine Linux の GitLab は標準の Ruby を使用していたため、GitLab を 19.3.6 へ更新しても、このパッチは適用されませんでした。

修正は GitLab が同梱する Ruby へのパッチ

GitLab 19.4.2 / 19.3.5 / 19.2.8 のバグ修正一覧には、Linux パッケージ（omnibus-gitlab）とクラウドネイティブイメージ（CNG）向けに、Ruby 3.3 / 3.4 の正規表現処理へパッチを追加する変更が含まれています。Ruby 本体の修正版（3.3.13 など）が公開されたのは 10月23日で、GitLab の修正版公開より後でした。

つまり、GitLab 19.3.6 自体が未修正だったわけではありません。GitLab が配布する 19.3.6 の Linux パッケージやコンテナーイメージには、パッチ済みの Ruby が含まれます。Alpine Linux の事例で問題となったのは、GitLab の公式配布物を使わず、Ruby を自前で用意していた点です。

Ruby の修正版と CVE-2026-110264 との違い

Ruby は 10月23日に 4.0.9 / 3.4.12 / 3.3.13 を公開し、GitLab が採番した 4 件の CVE に関係する不具合をまとめて修正しました。このうち、CVE-2026-97229 と、10月21日に別途公開された CVE-2026-110264 は、原因となる Ruby の不具合と修正版が異なります。

参考: Ruby（Regexp compilation fixes related to GitLab’s CVEs）
“Ruby 4.0.9, 3.4.12 and 3.3.13 contain all of these fixes.”
（Ruby 4.0.9、3.4.12、3.3.13 には、これらの修正がすべて含まれています）
https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/

Ruby 4.0.8 には CVE-2026-97229 に対応する修正が含まれますが、CVE-2026-110264 に対応する修正は含まれません。独自に Ruby を用意する場合は、Ruby 公式が推奨する 4.0.9 / 3.4.12 / 3.3.13 以降を基準にすると、両方の CVE に対応できます。

ただし、GitLab のすべての系列が、これら 3 つの Ruby 系列のいずれでも動作するわけではありません。独自ビルドでは、利用中の GitLab がサポートする Ruby 系列を確認し、その系列の修正版または同等のパッチ適用版を使用してください。GitLab のソースからのインストールガイドは、インストールする GitLab のバージョンに対応したブランチの版を参照するよう求めています。Ruby の要件は、そのバージョンのガイドで確認してください。

Onigmo の修正内容や Ruby アプリケーション全般への影響は『Ruby の正規表現脆弱性（2026年10月）｜影響確認と更新判断』、CVE-2026-110264 の影響範囲と GitLab の修正版の選び方は『CVE-2026-110264 GitLab｜修正版の選び方と侵害確認』で解説しています。

また、Linux ディストリビューションの Ruby パッケージは、上流のバージョン番号を変えずに修正をバックポートしている場合があります。逆に、GitLab 公式配布物の Ruby は、Ruby の修正版の公開前からパッチで修正しているため、表示されるバージョン番号が上表より小さい場合もあります。バージョン番号の比較だけで判断せず、配布元のセキュリティ情報やパッケージの変更履歴も確認してください。

同じイメージタグでも取得時点で中身が異なる

Alpine Linux によると、10月27日に公開された alpinelinux/gitlab:19.3.6 には Ruby 3.3.13 が含まれます。一方、10月27日より前に取得した 19.3.6 イメージと、それより古いタグはすべて脆弱です。

同じ 19.3.6 タグでも、取得した時点によって中身が異なります。タグ名やバージョン番号だけを記録している運用では、どちらのイメージが稼働しているかを判別できません。コンテンツから算出される識別子であるイメージ digest で、取得済みのイメージと稼働中のコンテナーを確認することをおすすめします。また、新しいイメージを取得しても、既存のコンテナーは作成時のイメージのまま動作し続けるため、コンテナーの再作成が必要です。

自社 GitLab の影響判定と修正状況の確認

影響判定は「GitLab のバージョン」と「実際に稼働している Ruby」の 2 段階で考えます。公式配布物では前者で判断できますが、独自ビルドでは後者の確認が欠かせません。

sudo gitlab-rake gitlab:env:info

bundle exec rake gitlab:env:info RAILS_ENV=production

sudo -u git -H bundle exec rails runner -e production "puts RUBY_DESCRIPTION"

readlink /proc/<PID>/exe

docker inspect --type=container --format '{{.Image}}' <コンテナー名>

docker image ls --digests --no-trunc <イメージ名>

kubectl get pods -n <namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}'

ホスト OS で実行した ruby -v の結果は、PATH やバージョンマネージャーの設定によって、GitLab のプロセスが使う Ruby と異なる場合があります。GitLab の公式ドキュメントも、RVM や rbenv などのバージョンマネージャーは原因の特定が難しい問題につながり得るとしています。

攻撃痕跡の調査と再構築の判断

修正版を適用しても、修正前に受けた攻撃の影響が残っている可能性はあります。修正前に外部から到達可能だった GitLab は、ログを確認したうえで、侵害を否定できるかを判断してください。

調査対象の期間を決める

調査対象は、脆弱な状態で運用していた期間です。独自の Ruby を使う環境では、GitLab を更新した日ではなく、修正済みの Ruby が実際に稼働し始めた日までを調査対象に含めてください。Alpine Linux の事例でも、10月22日に GitLab を更新した後の 10月25〜26日に、攻撃者が再びアクセスを試みています。

GitLab が公開した 6 種類の検知ルール

GitLab は、Self-Managed 環境向けに CVE-2026-97229 の悪用試行を検知する 6 種類のルールを公開しています。

• 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

ルール名からは、ワーカープロセスのクラッシュ、CI Lint や GraphQL を経由した正規表現の送信、エラーの急増などを観点としていることが読み取れます。各ルールのログソースや検知条件は、リンク先の最新版を確認してください。なお、CVE-2026-110264 向けにも、Onigmo native worker crash を含む 2 種類のルールが公開されています。

ログで確認するポイント

クラッシュやエラーが記録されていないことは、攻撃が成功していない根拠になりません。Alpine Linux は、攻撃が成功した場合はクラッシュも Web ログの痕跡も残らないと説明しています。外向き通信のログや、ログの保存期間が十分かどうかも、調査結果の確度に影響します。Alpine Linux は再発防止策として、外向き通信とデータベース接続の記録や、14 日を超えるログ保存を挙げています。

侵害を否定できない場合の対応

痕跡の有無とログの十分さによって、取るべき対応は変わります。Alpine Linux が実施した再構築や全ユーザーのパスワードリセットは、ログの欠損などで侵害を否定できなかった状況での判断であり、すべての GitLab 利用者に一律で求められる手順ではありません。

痕跡がなく、調査期間のログが十分に残っている

修正状況の確認結果と調査記録を残し、通常の運用へ戻ります。検知ルールの継続運用やログ保存期間の見直しを検討してください。

痕跡はないが、ログの欠損などで侵害を否定できない

外部公開の範囲、GitLab に保存している秘密情報の重要度、リスク許容度に応じて、認証情報のローテーションや再構築を検討します。

攻撃の痕跡が見つかった

再構築や認証情報の変更より先に、ログやディスクなどの証拠を保全します。そのうえで、インシデント対応の体制のもとで侵害範囲を調査し、再構築を含めた対応を判断します。

認証情報をローテーションする場合は、GitLab に保存されている秘密情報を洗い出します。Alpine Linux の再開時の案内では、パスワードと 2FA の再設定、個人アクセストークンの再発行、CI/CD 変数の再入力、連携機能・Webhook・プッシュミラー・OAuth アプリケーションのシークレット更新が挙げられています。CI/CD 変数に外部サービスの認証情報を保存している場合は、GitLab 側の再設定だけでなく、発行元での失効と再発行も検討してください。

また、Alpine Linux は再開後、メールアドレスとパスワードで登録する新規アカウントを管理者の承認制に変更しています。公開型の GitLab では、新規登録の扱いもあわせて見直すことをおすすめします。

まとめ

CVE-2026-97229 は、GitLab の修正が同梱 Ruby へのパッチとして提供された脆弱性です。Alpine Linux の事例は、製品のバージョン番号だけでは修正状況を判断できない構成があることを示しています。独自ビルドでは、実際に稼働している Ruby とイメージまで確認することが重要です。

• CVE-2026-97229 は CI/CD 設定の正規表現に起因する CVSS 10.0 の脆弱性です。
• Alpine Linux では攻撃試行が確認され、侵害を否定できず再構築に至りました。
• 公式配布物は 19.2.8 / 19.3.5 / 19.4.2 以降への更新で修正が入ります。
• 独自 Ruby の環境では、修正済み Ruby が稼働しているかを確認します。
• コンテナーはタグではなく digest で稼働中のイメージを確認します。
• 調査期間は修正済み Ruby が稼働し始めた日までを含めて設定します。
• クラッシュがないことは、攻撃が成功していない根拠になりません。

以上、最後までお読みいただきありがとうございました。