Convika
無料で始める

Ruby 4.0.9・3.4.12・3.3.13 正規表現の脆弱性：更新する版と確認方法

Convika Team読了目安: 16 分

  • security
  • ruby
  • rails
  • gitlab
目次

情報は 2026 年 10 月 24 日 8 時 3 分（日本時間）時点です。ruby-lang.org の発表の日本語版は、8 時 36 分に確かめたときもまだ出ていません。ツールや配布元の対応は数時間で変わるので、最新は各出典で確かめてください。

2026 年 10 月 23 日、Ruby は正規表現エンジン（Onigmo）のバグを直した Ruby 4.0.9・3.4.12・3.3.13 を公開しました（発表は日本時間 12 時 11 分、UTC 3 時 11 分）。GitLab が CVE-2026-110264 など 4 件の CVE として公開した脆弱性の、元になったバグです。Ruby によると、影響を受けるのは攻撃者が決められる文字列から正規表現を作るアプリだけで、自分で書いた正規表現しか使わないアプリは影響を受けません。入力から正規表現を作っているなら修正版に更新し、すぐに更新できないなら、信頼できない入力から正規表現を作るのをやめてください。

この記事は、Ruby や Rails でアプリを動かしている人と、GitLab を自分で運用していて Ruby も直すべきかを知りたい人に向けて書いています。自分のアプリが当てはまるかの調べ方、入れ方ごとの更新のしかた、修正の出ない Ruby 3.2 以前の扱いを、出典と確認した日時つきで並べます。

結論：どの版に更新するか

Ruby は、4.0.9・3.4.12・3.3.13 かそれ以降への更新を勧めています。いま使っている系列（バージョンの 2 つ目の数字まで）の修正版に上げるのが、いちばん小さな変更です。

使っている系列更新先Ruby のブランチのページの状態補足
4.04.0.9通常メンテナンス前の日に出た 4.0.8（10 月 22 日）には、CVE-2026-110264 の元になったバグの修正が入っていない
3.43.4.12通常メンテナンスほかの不具合の修正も入っている
3.33.3.13セキュリティメンテナンス。EOL は 2027 年 3 月 31 日の見込みふだんは脆弱性の修正だけを出す時期で、今回の修正は例外として入れた。resolv gem を 0.3.2 にする修正（CVE-2026-80212・CVE-2026-80213）も入っている
3.2 以前修正版は出ない。3.3.13 以降へ移るeol。3.2 の EOL は 2026 年 4 月 1 日3.2 の最後のリリースは 3.2.11（2026 年 3 月 27 日）

3 つの版は、どれも 10 月 23 日の公開です（Ruby のリリース一覧。ブランチのページとあわせて 10 月 24 日 7 時 52 分に確認）。

自分のアプリは影響を受けるか

Ruby の発表は、影響を受ける条件を次のように書いています。

  • 影響を受ける: 攻撃者が決められる文字列から正規表現を作る（コンパイルする）アプリ。例として、その文字列を Regexp.new・Regexp.union・Regexp.compile に渡す場合と、/#{input}/ のように正規表現の中に埋め込む場合を挙げています。
  • 影響を受けない: 開発者が自分で書いた正規表現だけを使うアプリ。
  • タイムアウトでは防げない: Regexp.timeout では防げません。パターンの長さを制限しても、確実には防げません。短いパターンで起きるバグもあるからです。

当てはまりやすいのは、利用者が書いた文字列を正規表現として使う機能です。たとえば、検索欄の「正規表現で検索」、管理画面の絞り込みのルール、設定画面で書いた正規表現で入力をチェックする機能、データベースに保存した文字列から作るルーティングの制約です。ログインした人しか使えない画面でも、だれでも登録できるサービスなら、攻撃者もその画面に入れます。GitLab の 4 件のうち 2 件は、ログインした利用者による攻撃として登録されています（CVE の記録）。

調べ方：grep で正規表現を作っている行を探す

アプリのフォルダで、次のコマンドを実行します。macOS の grep と GNU grep で動くことを、10 月 24 日に確かめました。

grep -rnE --include='*.rb' --include='*.rake' --exclude-dir=vendor 'Regexp\.(new|union|compile)|%r.*#\{|/[^/]*#\{[^}]*\}[^/]*/' .

見つかった行ごとに、正規表現の元になる文字列がどこから来るかを見ます。

文字列の出どころ当てはまるか
params、フォームの値、URL のクエリ当てはまる
利用者が保存できるデータベースの値、アップロードされたファイルの中身、外部の API の応答当てはまる
コードに書いた定数や文字列だけ当てはまらない
"/users/#{id}/edit" のようなパスの文字列正規表現ではないので関係ない（この grep は拾ってしまう）

この grep は自分のコードだけを見ます。依存している gem の中で入力から正規表現を作っているかどうかはわからないので、当てはまる行がなくても、更新はしておくのが確実です。

何が起きたか：GitLab の 4 件の CVE と Ruby の修正

GitLab は、CI の設定に書かれたパターンなど、利用者が書いた正規表現を Regexp.new で作っています。GitLab は、細工したパターンで Ruby が正規表現を作る途中のメモリを壊せること、それを GitLab のサーバーでのリモートコード実行（ネット越しに好きなプログラムを動かされること）につなげられることを見つけました。GitLab は、自社が配る Ruby に修正を当てて自社のリリースで直し、4 件の CVE を出しました。ここまでは Ruby の発表に書いてあることです。

GitLab の CVERuby 側のバグ直った最初の版（4.0・3.4・3.3）
CVE-2026-89078パターンの解析が、選択（いくつかの候補のどれかに合う形）のあとで失敗したときの二重解放4.0.0・3.4.12・3.3.13
CVE-2026-93577、CVE-2026-97229組み立てた正規表現のサイズの整数オーバーフロー4.0.8・3.4.12・3.3.13
CVE-2026-110264繰り返しの多いパターンでの、内部の ID のオーバーフロー4.0.9・3.4.12・3.3.13

4.0.9・3.4.12・3.3.13 には、この 3 つの修正がすべて入っています。

時系列は次のとおりです。CVE の公開日時と GitLab の修正版は CVE.org の記録（GitLab が登録）、それ以外は Ruby の発表とリリース一覧によります。

  • 9 月 24 日 8 時 4〜5 分（UTC 9 月 23 日 23 時 4〜5 分）: CVE-2026-89078 と CVE-2026-93577 が公開。どちらもログインした利用者による攻撃で、CVSS v3.1 は 9.9（GitLab の評価）。GitLab 19.4.1 など各系列の修正版で直った
  • 10 月 13 日 10 時 5 分（UTC 1 時 5 分）: CVE-2026-97229 が公開。ログインなしの攻撃で、CVSS v3.1 は 10.0。GitLab 19.4.2 など各系列の修正版で直った
  • 10 月 22 日 9 時 33 分（UTC 0 時 33 分）: CVE-2026-110264 が公開。ログインなしの攻撃で、CVSS v3.1 は 10.0。GitLab 19.5.1 など各系列の修正版で直った（GitLab のリリースは 10 月 21 日）
  • 10 月 22 日: Ruby 4.0.8。発表では「定期的な不具合修正」だが、上の表のとおり CVE-2026-93577・CVE-2026-97229 の元のバグの修正が入っている
  • 10 月 23 日 12 時 11 分（UTC 3 時 11 分）: Ruby の発表と、4.0.9・3.4.12・3.3.13

CVSS の点数は GitLab のサーバーでの評価で、Ruby で作ったアプリ一般の深刻度ではありません。Ruby の発表と 4 件の CVE の記録に、悪用されたという記載はありません。米国の CISA の悪用済み脆弱性カタログ（KEV）にも、4 件とも載っていません（カタログ 2026.10.23 版、10 月 24 日 7 時 53 分に確認）。

Ruby 側の CVE はまだない

Ruby は、この修正について Ruby 側の CVE を「少なくとも今のところ」取っていません。Ruby はこれまで、信頼できない入力から作った正規表現を使うのは安全でないという立場をとってきました。それでも CVE-2022-28738 と CVE-2024-27282 では、正規表現のコンパイルの欠陥を脆弱性として扱っています。いまの Regexp のドキュメントは、信頼できないパターンをサービス妨害（DoS）の面からしか扱っておらず、タイムアウトを勧めているだけです。

Ruby は、信頼できないパターンのコンパイルを Ruby がサポートする使い方としてドキュメントに書くか、この種の問題を Ruby の脆弱性として扱うか、CVE を取るかを話し合う予定で、取ったら発表のページを更新するとしています。それまでは、セキュリティスキャナーなどで追うときは GitLab の CVE 番号を使うよう求めています。

GitLab を自分で運用している場合

Ruby の発表によると、GitLab は自社が配る Ruby に修正を当てて直しています。GitLab の 10 月 21 日のリリースの修正一覧にも、Ruby の正規表現の修正を 3.3・3.4・4.0 に当てたことが載っています。GitLab が配る Linux パッケージや Docker イメージで入れているなら、することは GitLab の修正版への更新です。ソースから入れた GitLab は、自分で入れた Ruby で動きます。GitLab のリリースは、その場合に GitLab の更新だけで直るかを書いていないので、Ruby も修正版に上げておくのが確実です。上げる版と手順は GitLab CVE-2026-110264: which version to upgrade to and how（英語）にまとめています。

更新の手順

1. 動いている Ruby の版を確かめる

手元では ruby -v で、アプリが使う版はアプリのフォルダで bundle exec ruby -v で見ます。修正版なら ruby 3.4.12 (2026-10-23 revision …) のように、10 月 23 日の日付が出ます。版の指定は .ruby-version、.tool-versions、mise.toml、Gemfile の ruby の行、Gemfile.lock の RUBY VERSION、Dockerfile の FROM のどこかにあるので、全部を見ます。本番は、アプリを動かしているのと同じ環境で ruby -v を実行して確かめます。

2. 入力から正規表現を作っている箇所を探す

上の「調べ方」の grep をアプリのフォルダで実行し、見つかった行の文字列がどこから来るかを見ます。当てはまる行があれば、その機能は更新が終わるまで次の節の対策をとります。当てはまる行がなくても、依存している gem の中は見ていないので、更新は進めます。

3. 修正版の Ruby を入れる

入れ方ごとの対応は、次の表のとおりです。表のどの入れ方でも、10 月 24 日の朝までに 3 つの版がそろっています。コマンドは 3.4 の場合の例です。

入れ方修正版が出たとき（日本時間）コマンドの例
rbenv（ruby-build）10 月 23 日 13 時 47 分（UTC 4 時 47 分）、ruby-build v20261023brew upgrade ruby-build（Homebrew で入れた場合）か git -C "$(rbenv root)"/plugins/ruby-build pull のあと、rbenv install 3.4.12
asdf10 月 23 日 15 時 47 分（UTC 6 時 47 分）、asdf-ruby が ruby-build v20261023 に切り替えasdf plugin update ruby のあと、asdf install ruby 3.4.12
mise10 月 23 日 21 時 18〜19 分（UTC 12 時 18〜19 分）、ビルド済みの Ruby（jdx/ruby）mise use ruby@3.4.12
Homebrew時刻の記載なし。10 月 24 日 7 時 54 分に、ruby が 4.0.9、ruby@3.4 が 3.4.12、ruby@3.3 が 3.3.13 なのを確認brew update のあと、brew upgrade ruby@3.4（4.0 なら ruby）
Docker 公式イメージ ruby10 月 24 日 4 時 58 分ごろ〜5 時 2 分（UTC 23 日 19 時 58 分ごろ〜20 時 2 分）、タグの最終更新FROM ruby:3.4.12 にして、docker build --pull で作り直す
Windows（RubyInstaller）10 月 24 日 5 時 33〜39 分（UTC 23 日 20 時 33〜39 分）Ruby+Devkit 3.4.12-1 を入れ直す
GitHub Actions（ruby/setup-ruby）10 月 23 日 14 時 16 分（UTC 5 時 16 分）、v1.334.0ruby/setup-ruby@v1 で ruby-version: '3.4' のように系列だけ書いていれば、次の実行から 3.4.12。版まで書いているなら書き換える
Heroku10 月 23 日（変更履歴の日付）。新しいアプリの標準も 3.4.12 になった手元に 3.4.12 を入れ、Gemfile の ruby の行を書き換えて bundle update --ruby を実行し、デプロイ

Docker の公式イメージでは、ruby:4.0 と ruby:latest が 4.0.9、ruby:3.4 と ruby:3 が 3.4.12、ruby:3.3 が 3.3.13 を指しています（公式イメージの定義）。10 月 24 日 8 時 3 分に ruby:3.4.12-slim、ruby:4.0-slim、ruby:3.3-slim で Ruby の版を出し、それぞれ 3.4.12・4.0.9・3.3.13 と表示されるのを確かめました。系列のタグを使っていても、手元やビルドのサーバーに古いイメージが残っていると古い Ruby のままなので、--pull をつけて作り直します。

Heroku は Gemfile.lock の RUBY VERSION に書かれた版を入れます。bundle update --ruby は、そこに書かれた版を、いま動いている Ruby の版に書き換えるコマンドです（Bundler の説明）。

4. 版の指定を書き換えて、テストを通す

.ruby-version など、手順 1 で見つけた版の指定をすべて新しい版に書き換え、bundle install で gem を入れ直してから、テストを通します。rbenv・asdf・mise では、Ruby の版ごとに gem が別の場所に入るので、新しい版では入れ直しが要ります。CI の設定に版を書いているなら、そこも書き換えます。

5. デプロイして、本番の版を確かめる

Ruby を入れ替えても、動いているプロセス（Puma や Sidekiq など）は、再起動するまで前の Ruby のままです。デプロイか再起動のあと、手順 1 と同じ方法で、本番で動いている版が修正版になったのを確かめます。

すぐに更新できない場合

Ruby の案内は 1 つで、信頼できない入力から正規表現を作らないことです。たとえば、利用者が書いた正規表現で探す機能を一時的に止める、正規表現をやめて include? や start_with? のような文字列の比較で探す、といった形です。

タイムアウトや長さの制限は、代わりになりません。Ruby は、Regexp.timeout ではこれらのバグを防げず、パターンの長さの制限も確実ではないとしています。

Ruby 3.2 以前を使っている場合

修正版は出ません。Ruby のブランチのページは 3.2 を eol とし、EOL を 2026 年 4 月 1 日としています（日本語版も同じ。10 月 24 日 7 時 52 分に確認）。同じページは eol を、ruby-core チームのサポートが終わり、どの修正も受け取らず、パッチリリースももう出ない段階と書いています。今回の Ruby の発表は 3.2 に触れておらず、修正した版にも挙げていません。

3.2 の最後のリリースは 3.2.11（2026 年 3 月 27 日）です。3.2 を配る側も止まりつつあります。

  • Docker 公式イメージ: 公式イメージの定義に 3.2 のタグはありません。Docker Hub の ruby:3.2 は 2026 年 4 月 14 日の更新が最後です。
  • Homebrew: ruby@3.2 は 3.2.11 のままで、2026 年 5 月 7 日から非推奨（理由は「unsupported」）、2027 年 5 月 7 日に使えなくなる予定です。
  • Heroku: Ruby の対応表で、3.2 は「EOL」と書かれ、版は 3.2.11 です。

入力から正規表現を作っているなら、3.3.13 以降へ移ります。移るなら 3.4.12 か 4.0.9 を勧めます。3.3 も、あと 5 か月ほどの 2027 年 3 月 31 日にサポートが終わる見込みだからです（3.4 と 4.0 の終わりは未定）。系列が変わると gem を入れ直す必要があり、動かなくなる gem が出ることもあるので、テストを通してから本番に出します。

配布元の対応状況

apt や dnf で入れた OS のパッケージの Ruby について、各配布元のページに書いてあることだけを並べます。

配布元書いてあること確認した日時
Debianセキュリティトラッカーは 4 件とも「NOT-FOR-US: GitLab」（GitLab のもの）としていて、ruby3.3・ruby3.1 の未修正の一覧に載っていない。修正の予定は記載なし。trixie の ruby3.3 は 3.3.8-2、bookworm の ruby3.1 は 3.1.2-7+deb12u110 月 24 日 7 時 55 分
UbuntuCVE-2026-97229 だけ項目があり、対象は gitlab のパッケージだけ。ほかの 3 件は項目なし。Ruby のパッケージの記載なし10 月 24 日 7 時 55 分と 8 時 1 分
Red Hat4 件とも、Red Hat の CVE のデータに項目なし10 月 24 日 7 時 55 分〜8 時 0 分

配布元が 4 件を Ruby のパッケージに結びつけていないので、CVE 番号で調べるスキャナーには出てこないことがあります。OS のパッケージの Ruby で動かしていて、入力から正規表現を作っているなら、配布元の修正を待たずに「すぐに更新できない場合」の対策をとるか、上の表の入れ方で修正版の Ruby に移ります。

よくある質問

Ruby の脆弱性は Rails に影響しますか？

Rails のアプリも Ruby の上で動くので、条件は同じです。アプリや使っている gem が、攻撃者が決められる文字列から正規表現を作っていれば影響を受け、開発者が書いた正規表現だけなら影響を受けません。Ruby の発表は Rails に触れていません。Rails のアプリでも、Ruby を修正版に上げてデプロイするのが確実です。

Ruby 3.3.13 に上げれば安全ですか？

今回の 4 件の元になったバグは、3.3.13 で直っています。3.3.13 には、resolv gem の 2 件の脆弱性（CVE-2026-80212・CVE-2026-80213）の修正も入っています。ただし 3.3 はセキュリティメンテナンスの時期で、2027 年 3 月 31 日にサポートが終わる見込みです。

Regexp.timeout で防げますか？

防げません。Ruby の発表は、Regexp.timeout ではこれらのバグを防げず、パターンの長さを制限しても確実には防げないとしています。短いパターンで起きるバグもあるからです。

Regexp.escape した入力から作った正規表現なら大丈夫ですか？

Ruby の発表には書いてありません。この記事では、大丈夫とも危ないとも言いません。入力から正規表現を作っているなら、修正版に更新してください。

Ruby 3.2 は修正されますか？

修正版は出ません。Ruby のブランチのページは 3.2 を eol（2026 年 4 月 1 日）とし、eol の系列にはどの修正も出ず、パッチリリースももう出ないと書いています。今回の Ruby の発表も、修正した版に 3.2 を挙げていません。3.3.13 以降に移ります。

Ruby のバージョンはどう確かめますか？

ruby -v で表示されます。アプリが使う版は、アプリのフォルダで bundle exec ruby -v を実行するか、.ruby-version や Gemfile.lock の RUBY VERSION を見ます。修正版なら、ruby 3.4.12 (2026-10-23 revision …) のように 10 月 23 日の日付が出ます。

GitLab の脆弱性と Ruby の脆弱性は同じものですか？

元は同じバグです。GitLab は利用者が書いたパターンから正規表現を作るので、Ruby の正規表現エンジンのバグが GitLab のサーバーでのリモートコード実行につながり、GitLab が 4 件の CVE を出しました。Ruby の修正版は、その元のバグを直したものです。GitLab ではない Ruby のアプリは、入力から正規表現を作っているときだけ当てはまります。

CVE は Ruby 側で発行されていますか？

今のところ発行されていません。Ruby は、この修正について CVE を取るかどうかを話し合う予定で、取ったら発表のページを更新するとしています。それまでは、GitLab の CVE 番号（CVE-2026-89078・CVE-2026-93577・CVE-2026-97229・CVE-2026-110264）で追うよう求めています。

Ruby 4.0.8 では足りませんか？

足りません。4.0.8（10 月 22 日）には CVE-2026-89078 と CVE-2026-93577・CVE-2026-97229 の元のバグの修正は入っていますが、CVE-2026-110264 の元のバグの修正は 4.0.9 からです（Ruby の発表の表）。

この脆弱性は悪用されていますか？

Ruby の発表と 4 件の CVE の記録には、悪用されたという記載はありません。CISA の悪用済み脆弱性カタログ（KEV）にも載っていません（10 月 24 日 7 時 53 分に確認）。

出典

更新の記録

  • 2026 年 10 月 24 日: 公開。出典は 10 月 24 日 7 時 52 分〜8 時 3 分（日本時間）に読んだものです。

関連記事

記事を共有する