GitLab CVE-2026-97229（CVSS 3.1 で 10.0）は、CI 設定に仕込んだ正規表現から未認証でサーバ上のコード実行に至りうる問題です。2026年10月13日に GitLab が公表しましたが、その約1週間後、修正版が出ているはずの環境でも悪用が試みられました。狙われたのは Alpine Linux プロジェクト自身の GitLab サーバで、Alpine は10月28日に経緯を公表しています。

やっかいなのは、Alpine が GitLab を新しい版へ上げていたのに穴が塞がっていなかった、という点です。原因はこの脆弱性の根っこが GitLab ではなく Ruby の正規表現エンジン Onigmo にあり、GitLab のアップグレードだけでは自前の Ruby が置き換わらなかったことにあります。依存する処理系の脆弱性がどう伝わるかの全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。この記事は、何が起きたか・なぜ GitLab を上げても直らなかったか・自分のサーバが本当に直っているかの確かめ方を、一次情報で整理します。攻撃を再現する手順（PoC）は載せません。

WHAT HAPPENED時系列

修正の1週間後、Alpine の GitLab が狙われた

  1. 10/13

    GitLab が CVE-2026-97229 を公表（CVSS 10.0）

    CI の正規表現から未認証でコード実行に至りうる。修正版は 19.2.8 / 19.3.5 / 19.4.2（CVE 記録）

  2. 10/20–21

    新規登録の口座が細工した CI 設定を送る

    Alpine によると worker を8回クラッシュさせ、うち4回は最初の段を越えた。502 エラーも発生

  3. 10/22

    19.3.6 へ上げたが、まだ脆弱だった

    Alpine のイメージは標準 Ruby を使っていたため、GitLab を上げても穴が塞がらなかった（10/26 に判明）

  4. 10/27–28

    サーバを作り直し、全口座のパスワードを初期化

    成功の証拠は無いが否定もできないとして侵害扱い。署名鍵は GitLab サーバに置いていなかった

出典: Alpine Linux 公式声明（GitLab-security-incident-CVE-2026-97229）、CVE-2026-97229 記録、Ruby 公式リリース（2026-10-29 確認）

30秒でわかる

  • ・CVE-2026-97229（CVSS 10.0）は、CI 設定の細工した正規表現から未認証でコード実行に至りうる GitLab の問題。影響は 19.2 / 19.3 / 19.4 系列。
  • ・バグの本体は Ruby の正規表現エンジン Onigmo。GitLab はそれを使って CI の正規表現をコンパイルするため、サーバの未認証RCEに転じうる。
  • ・GitLab 公式パッケージ・公式イメージは同梱 Ruby ごと直る。だが自前ビルドや Ruby を別に入れる独自イメージは、GitLab を上げても穴が残る。
  • ・Alpine は 19.3.6 へ上げた後も脆弱で、実際に悪用を試みられた。恒久策は Ruby を 3.3.13 / 3.4.12 / 4.0.9 以上へ上げること。

時系列：修正の1週間後に、GitLab サーバが狙われた

GitLab は CVE-2026-97229 を2026年10月13日に公表しました（CVE 記録の公開も同日）。Alpine によると、同プロジェクトの GitLab サーバ gitlab.alpinelinux.org では、新しく登録された口座が10月20日と21日に細工した CI 設定を送り込み、GitLab の worker プロセスを8回クラッシュさせました。Alpine は、そのうち4回は攻撃の最初の段（正規表現によるクラッシュ）を越えて次の段で失敗したと説明しています。攻撃者は Alpine の GitLab コンテナイメージをダウンロードしており、Alpine は「自分たちのビルドに合わせて攻撃を調整していたことを示唆する」と述べています。

Alpine はこの口座を10月23日にブロックしましたが、攻撃者は25日・26日にも再侵入を試みています（いずれも失敗）。そして10月26日、Alpine は「22日に 19.3.6 へ上げたのに、まだ脆弱なままだ」と気づきました。翌27日にサーバを開発者とビルドサーバ以外に閉じ、作り直しを開始。28日に再構築を終え、GitLab の秘密鍵を入れ替え、修正済みの Ruby（3.3.13 以上）で動かし直しています。

攻撃の「成功」は確認されていない

  • ・Alpine は、攻撃者のコードがサーバ上で動いた痕跡は見つからなかったとしています（応答遅延なし・不審なファイルや鍵やプロセスなし・外部への情報送信も確認できない）。
  • ・一方で、「成功した悪用はクラッシュも web ログの痕跡も残さない」とも述べ、攻撃日の一部ログ（バックグラウンドジョブのログや旧コンテナのファイルシステム）が失われているため、成功を否定できないとしています。
  • ・確定できない以上、Alpine はサーバを侵害扱いし、足がかりを残さないために作り直しました。これは過剰反応ではなく、証拠が消えた環境での妥当な判断です。

GitLab CVE-2026-97229 で何が起きたか：正規表現から未認証RCEへ

CVE の公式記録は、この問題を「正規表現の検証が不十分なために、特定の条件下で未認証のユーザーが CI/CD 設定の細工した正規表現を通じてサーバ上で任意コードを実行できた可能性がある」と説明しています。CWE 分類は CWE-190（整数オーバーフロー）で、CVSS 3.1 ベクトルは AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H——ネットワーク経由・低い攻撃条件・権限不要・利用者操作不要で、機密性・完全性・可用性すべてに高い影響、という最も重い部類です。

GitLab は CI 設定に書かれた正規表現を Ruby でコンパイルします。その Ruby の正規表現エンジン Onigmo のコンパイル処理に欠陥があり、細工したパターンでメモリが壊れ、最悪の場合コード実行に至る——これが GitLab サーバの未認証RCEとして現れる、という筋道です。Onigmo 側のバグそのものと、どんな Ruby アプリが影響するか（攻撃者が制御する文字列から正規表現を作っているか）は、Ruby 正規表現エンジンOnigmoにRCEの問題｜GitLab発見の4件と、信頼できない入力からのRegexpコンパイルで詳しく扱っています。

なお、セキュリティ企業 Rapid7 は10月13日に実験室で動く PoC を公開しています。彼らが試した経路では「未認証なのは最後の CI lint リクエストだけ」で、その前に攻撃者が公開プロジェクトのブランチへ悪意ある .gitlab-ci.yml と特定のファイルパスを書き込む必要があります。つまり、誰でも登録してプロジェクトを作れるサーバでは、この「書き込みの前提」が自然に満たされてしまうという点が、Alpine のような公開 GitLab にとって重い意味を持ちます。本記事では攻撃を再現する具体的な入力や手順は扱いません。

なぜ GitLab CVE-2026-97229 は上げても直らなかったのか

ここがこの事件のいちばんの教訓です。GitLab が10月の更新で行った修正は、GitLab が自社のパッケージやコンテナイメージに同梱している Ruby にパッチを当てることでした。Ruby 本体の修正版（3.3.13 / 3.4.12 / 4.0.9）が出たのは、少し遅れて10月22〜23日です。

GitLab のアップグレードは、サーバに入っている Ruby 自体を入れ替えるわけではありません。したがって、標準の（あるいは自前でビルドした）Ruby の上で GitLab を動かしている環境は、GitLab の更新（GitLab Ruby 更新と混同されがちですが、両者は別物です）だけでは「GitLab アップグレード 直らない」状態が続き、Ruby を修正版へ上げるまで穴が残ります。Alpine の alpinelinux/gitlab イメージは標準 Ruby を使っていたため、GitLab を 19.3.6 へ上げても塞がらなかった、というわけです。この構図は「Onigmo RCE」——正規表現エンジンのバグがアプリ（ここでは GitLab）の RCE に転じる——という言葉で語られます。

WHO IS FIXEDどちらの構成か

バグは Ruby にある。GitLab を上げれば直る構成と、直らない構成

GitLab を上げれば直る

GitLab を上げても直らない

GitLab を上げれば直る: 公式 Linux パッケージ（Omnibus）

GitLab を上げても直らない: ソースからの自前ビルド

GitLab を上げれば直る: GitLab 公式のコンテナイメージ

GitLab を上げても直らない: Ruby を別に入れる独自イメージ（Alpine の例）

GitLab を上げれば直る: 同梱 Ruby ごとパッチ版が入る

GitLab を上げても直らない: システムの Ruby は変わらない＝穴が残る

GitLab を上げれば直る: 最新版へ上げるだけでよい

GitLab を上げても直らない: Ruby を 3.3.13 / 3.4.12 / 4.0.9 以上へ別途更新

出典: Alpine 公式声明、Ruby 公式リリース（Onigmo の修正・4 CVE を含む・2026-10-29 確認）。PoC は非掲載

自分の構成がどちらかは、次のように切り分けられます。

構成 GitLab アップグレードで直るか 追加で必要なこと
公式 Linux パッケージ（Omnibus） 直る 系列ごとの修正版（19.2.8 / 19.3.5 / 19.4.2 以上）へ上げる
GitLab 公式のコンテナイメージ 直る 同上（最新イメージを取得）
ソースからの自前ビルド 直らない GitLab 更新に加え、Ruby を 3.3.13 / 3.4.12 / 4.0.9 以上へ
Ruby を別に入れる独自イメージ 直らない 同上（イメージ内の Ruby を更新して再ビルド・再取得）

GitLab の系列ごとの上げ先（18.11〜19.5 のどの版へ上げるか）は、別記事GitLab 脆弱性 CVE-2026-110264｜CVSS 10.0の未認証RCE、系列ごとの修正版と確認手順に早見表があります。CVE-2026-110264 は、今回の21日のリリースで同時に直る別の正規表現の問題です。

自分のサーバは本当に直っているか：Ruby の版を確かめる

いちばん確実な「GitLab Ruby 版 確認」の方法は、GitLab の版ではなく、GitLab が実際に動かしている Ruby の版を見ることです。公式パッケージや公式イメージなら、GitLab に同梱された Ruby の版が返ります。

# GitLab が使っている Ruby の版を確認する（Omnibus / 公式イメージ）
sudo gitlab-rails runner 'puts RUBY_VERSION'
# 独自イメージ・自前ビルドなら、その Ruby を直接
ruby -v

返った版が 3.3.13 / 3.4.12 / 4.0.9 以上であれば、Onigmo の修正が入っています。3.4 系なら 3.4.12 以上、3.3 系なら 3.3.13 以上、4.0 系なら 4.0.9 以上、が目安です。Ruby 3.2 系は2026年4月にサポートが終わっており、この修正は提供されません。3.2 系で動かしている場合は、上記のいずれかへ上げる必要があります。

痕跡の確認は、GitLab が公表した指針（Sigma 形式の検知ルールに添えられたもの）に沿って、次のような防御的なチェックを行います。攻撃を再現するものではなく、侵害の兆候を探すためのコマンドです。

# git ユーザー所有の不審なファイルが /tmp に無いか
find /tmp -user git -maxdepth 2 2>/dev/null
# Puma / Sidekiq の予期しない子プロセスが無いか
ps -ef | grep -E 'puma|sidekiq' | grep -v grep
# git ユーザーの crontab / 公開鍵が書き換えられていないか
sudo crontab -l -u git 2>/dev/null; sudo ls -l ~git/.ssh/authorized_keys 2>/dev/null

コード実行の兆候が見つかった場合、GitLab の指針は「サーバを侵害扱いし、gitlab-secrets.json の秘密・すべての CI/CD 変数・すべての runner トークン・すべてのアクセストークンをローテーションせよ」と案内しています。兆候が無くても、ログが失われていて確定できないなら、Alpine のように作り直す判断が妥当な場面があります。

影響範囲：成功は未確認、しかし否定もできない

Alpine は「もし攻撃が成功していたら」として、全ユーザーのメールアドレス・氏名・IP アドレス、パスワードハッシュ、2FA の秘密・CI/CD 変数・runner トークン、Webhook や連携・push mirror の資格情報、個人アクセストークン（ハッシュで保存）、非公開リポジトリや機密 issue・MR などが露出しえたと列挙しています。実際に露出したかは確認できていません。

一方、肝心のパッケージ供給網については、Alpine は aports リポジトリ・パッケージ・10月21日のリリースが改ざんされていないことを、GitLab の外にある記録（開発者の手元の複製と45台のビルドサーバ）と突き合わせて確認したとしています。10月20〜24日にビルドされた全パッケージは、git.alpinelinux.org で公開された aports の変更から作られたもので、これには公式 Docker イメージの土台になる minirootfs も含まれます。パッケージとリリースに署名する鍵は、そもそも GitLab サーバに置いたことがない——これが被害を限定した最大の要因です。

WHAT TO DO対応の確認項目

Ruby の版まで確かめる・公式イメージは引き直す

  1. 1.GitLab が実際に動かしている Ruby の版を見る

    GitLab のバージョンではなく Ruby の版。3.3.13 / 3.4.12 / 4.0.9 未満なら未修正

  2. 2.自前ビルド・独自イメージは Ruby を更新

    GitLab のアップグレードだけでは Onigmo のバグは残る。Ruby 本体を修正版へ上げる

  3. 3.Alpine の alpinelinux/gitlab:19.3.6 は引き直す

    10/27 公開分が Ruby 3.3.13 入り。それ以前に取得した 19.3.6 と旧タグは脆弱

  4. 4.すぐ上げられないなら到達面を絞る

    匿名の公開プロジェクト参照・新規ユーザのプロジェクト作成・CI lint 経路を制限（恒久策は版の更新）

出典: Alpine 公式声明、Ruby 公式リリース、CVE-2026-97229 記録（2026-10-29 確認）

この記事の結論

  • ・CVE-2026-97229 の本体は Ruby の Onigmo。GitLab のアップグレードで直るのは「同梱 Ruby ごと入れ替わる」公式パッケージ・公式イメージだけ。
  • ・自前ビルドや Ruby を別に入れる独自イメージは、Ruby を 3.3.13 / 3.4.12 / 4.0.9 以上へ上げるまで穴が残る。確かめるべきは GitLab の版ではなく Ruby の版。
  • ・alpinelinux/gitlab:19.3.6 は10月27日公開分（Ruby 3.3.13 入り）へ引き直す。gitlab.alpinelinux.org の口座はパスワード再設定が必要。
  • ・誰でも登録・プロジェクト作成できる公開 GitLab は、書き込みの前提が満たされやすく、到達面を絞る緩和の価値が高い。

参照ソース