Ruby 4.0.9・3.4.12・3.3.13 の正規表現（Onigmo）の直し：当たるアプリと上げ方

2026年10月23日の12時11分（日本時間）に、4.0.9・3.4.12・3.3.13 を出したという告知が出ました（告知の UTC の時刻に 9 時間を足しました）。この3つの版は、Ruby の正規表現（文字の並びのパターン）を扱う部品 Onigmo の不具合をいくつか直した版です。GitLab が、GitLab のサーバー（GitLab を動かしているサーバー）で遠隔のコード実行（外から機械を好きに動かされること）に使えると見つけた不具合で、GitLab が4つの CVE（脆弱性に付ける世界共通の番号）を出しました。Ruby の版は、その元になった不具合の直しを含んでいます。

この4つの CVE の番号は、GitLab が GitLab の製品に付けたものです。Ruby 自身は、これらの直しに CVE の番号を求めていない（少なくとも今は）と、告知は書いています。日本語版の告知は、10月24日15時ごろの時点でまだありません（この記事は英語の告知をもとに書きました）。

先に答えを書きます。ここがいちばん大事なところです。

当たるのは、攻撃者が操れる文字列から正規表現を組み立てるアプリだけ、と告知は書いています。 例は、Regexp.new・Regexp.union・Regexp.compile に渡す形と、/#{input}/ のように正規表現の中に埋め込む形です。自分たちの開発者が書いた正規表現だけを使うアプリは、当たりません（→「告知の条件」）
上げる版は、4.0.9・3.4.12・3.3.13 以降です。 この3つには、直しが全部入っています。4.0 系は直しごとに入った版が違うので、4.0.8 の人も 4.0.9 へ上げます（→「4.0.9・3.4.12・3.3.13 なら、直しが全部入っている」）
上げられないなら、信用できない入力から正規表現を組み立てないよう、告知は書いています。 Regexp.timeout では防げず、パターンの長さを絞っても確かには防げない、とも書いています（→「すぐ上げられないときは？」）
自分の版は、ruby -v で見ます。 Bundler を使うアプリは bundle exec ruby -v です（→「自分の Ruby の版を見る：ruby -v」）（apt で入れた OS の Ruby は、版の番号では直ったか分かりません（→「OS の Ruby（apt）を使っている人は？」））
OS が配る Ruby（apt）に今回の直しが入ったかは、10月24日15時ごろに見た範囲では、追跡のページで確かめられません。 Ruby の CVE が無く、Ubuntu・Debian の追跡にこの件の行が無いためです。取れる道は2つです（→「OS の Ruby（apt）を使っている人は？」）

初心者がまずやることは、ruby -v で自分の Ruby の版を見ることです。4.0.9・3.4.12・3.3.13 より前なら、上げる予定を立て、自分のコードに4つの形があるかを探します。探して何も出なくても、当たらないとは決まりません（告知の4つの形は例です）。

書いてあることは、Ruby・GitLab の告知、CVE の記録・NVD、Ruby を入れる道具（ruby-build・rbenv・asdf・mise・Homebrew・Docker・RubyInstaller）、Debian と Ubuntu の追跡、公的機関の一覧などを、2026年10月24日の14時45分から15時1分ごろ（日本時間）に開いて確かめたものです。手元の出力は、同じ日の14時52分から15時ごろに、Mac と、公式の Docker のイメージの中で流しました。壊れた正規表現や、細工したパターンは流していません。

この記事でわかること

10月23日の Ruby の版が直したもの（正規表現の部品 Onigmo）と、GitLab が付けた CVE との関係
当たるアプリの条件（告知の原文）と、自分のコードの候補の探し方
上げる版（4.0.9・3.4.12・3.3.13）と、ruby-build・rbenv・asdf・mise・Homebrew・Docker・RubyInstaller で新しい版が出た時刻
OS の Ruby を使っている人の状況、3.3.13 の resolv の直し、3.2 以前
悪用は確認されているか（2026年10月24日時点）

10月23日に、Ruby で何があった？
自分のアプリは当たる？告知の条件で見る
上げる版と、系統
自分の Ruby の版を見る：ruby -v
どうやって上げる？入れ方ごと
1. Gemfile に ruby の版を書いているとき
OS の Ruby（apt）を使っている人は？
すぐ上げられないときは？
悪用はされている？（2026年10月24日時点）
よくある質問
まとめ
参考資料

10月23日に、Ruby で何があった？

Ruby の公式サイトは、10月23日に、正規表現の組み立てに関わる直しの告知と、4.0.9・3.4.12・3.3.13 の3つの版を出しました。告知の題は、GitLab の4つの CVE（CVE-2026-89078・CVE-2026-93577・CVE-2026-97229・CVE-2026-110264）に関わる、正規表現の組み立ての直しです。

告知が書いていること

3つの版の告知は、次のように書いています。各版の告知の時刻は、10月23日の12時11分から13時24分ごろです。

4.0.9: CVE-2026-110264 が使う不具合の直しを含む。
3.4.12: 4つの CVE が使う不具合の直しを含む。ほかの不具合の直しもある
3.3.13: セキュリティの直し（標準の gem の resolv。後の「3.3.13 には resolv の直しも入っている」）を含む。そして、例外として、正規表現の直しも入っている。3.3 はセキュリティ保守の段階で、ふつうは脆弱性の直しだけを出すが、GitLab が CVE を付けたので例外にした（理由は、正規表現の直しの告知にあります）、という説明

Ruby は、もともと「信用できない入力から作った正規表現を組み立てて使うのは安全ではない」としてきた、と告知は書いています。それでも、2022年（CVE-2022-28738）と2024年（CVE-2024-27282）には、正規表現の組み立ての不具合を脆弱性として扱った、とも書いています。また、Ruby の Regexp の文書は、信用できないパターンを、サービスを止める攻撃（DoS）の面からだけ書き、タイムアウトを勧めている、と告知は書いています。

出典: Ruby: Regexp compilation fixes related to GitLab's CVEs（英語）・Ruby 4.0.9・Ruby 3.4.12・Ruby 3.3.13・Ruby: CVE-2022-28738 の告知（英語）

たとえ話で見ると

お客さんが書いてきた「型紙」（パターン）を、店の機械が組み立てる（コンパイルする）場面を考えます。細工した型紙だと、組み立てるときに、機械の中の帳面（メモリ）が壊れることがあります。GitLab の場合は、これを使って、GitLab のサーバーを外から好きに動かされるおそれがあった、というのが GitLab の見つけたことです。

告知の言い方では、GitLab は、CI の設定の中のパターンのような、利用者が出した正規表現を Regexp.new で組み立てていて、細工したパターンが Ruby の組み立ての途中でメモリを壊せること、それを遠隔のコード実行につなげられることを、GitLab が見つけた、と書いています。不具合は、二重解放（同じメモリを二度手放す不具合）が1つ、整数のあふれ（数が入れ物に収まらなくなる不具合）が2つ、と数えられています。どんなパターンで壊れるかは、この記事には書きません。

CVE の番号と点数は、誰が付けた？

4つの CVE は、どれも GitLab が付けた番号です。Ruby の告知が並べている題と、GitLab の直った版は、次のとおりです（題は告知の英語を訳しました）。

CVE	GitLab の題	GitLab の直った版	CVE の記録の説明	GitLab が付けた CVSS 3.1 の点
CVE-2026-89078	正規表現の構文解析での二重解放	19.4.1 ほか	認証された利用者が、GitLab のサーバーでコードを動かせたかもしれない	9.9
CVE-2026-93577	正規表現のコンパイラでの整数のあふれ	19.4.1 ほか	同上	9.9
CVE-2026-97229	CI/CD の正規表現のコンパイラでの整数のあふれ	19.4.2 ほか	認証されていない利用者が、GitLab のサーバーでコードを動かせたかもしれない	10.0
CVE-2026-110264	正規表現のコンパイラでの整数のあふれ	19.5.1 ほか	同上	10.0

点数の読み方です。

点は、GitLab が GitLab の製品に付けた CVSS 3.1 の点です。Ruby に付いた点は、ありません。 CVSS は、脆弱性の深刻さを点数で表す共通の方式で、3.1 はその版の名前です。10月24日14時47分ごろに見た CVE の記録では、「当たる製品」の欄に書かれているのは、GitLab だけです
10月24日14時47分ごろに見た範囲では、NVD（アメリカの脆弱性のデータベース）は、4つとも GitLab の付けた点だけを載せていて、NVD 自身の点はありません
Ruby は、Ruby として CVE を求めていない（少なくとも今は）、と告知は書いています。セキュリティの検査の道具などでこの件を追うときは、GitLab の番号を使ってほしい、と告知は書いています。Ruby の脆弱性として扱うかは、これから話し合う、と告知は書いています
10月24日14時56分ごろに見た範囲では、Ruby のセキュリティのページの一覧に、10月23日の告知は載っていません。いちばん新しい項は、8月27日の resolv の告知です。載っていない理由は、書かれていません

CVE の番号が無い知らせの読み方は、脆弱性の知らせの読み方の「CVE の番号が無い知らせもある」にまとめています。

出典: CVE の記録（CVE-2026-89078・CVE-2026-93577・CVE-2026-97229・CVE-2026-110264）・NVD（CVE-2026-89078・CVE-2026-93577・CVE-2026-97229・CVE-2026-110264）・Ruby: セキュリティの告知の一覧（英語）

自分のアプリは当たる？告知の条件で見る

当たるかは、Ruby の版と、アプリが正規表現をどう作っているかで決まります。

告知の条件

告知は、当たる条件を次のように書いています。

These bugs are reached only when an application compiles a regular expression from a string that an attacker controls, for example by passing it to Regexp.new, Regexp.union or Regexp.compile, or by interpolating it into a regexp literal such as /#{input}/. Applications that only use regular expressions written by their own developers are not affected.

訳すと、「これらの不具合に届くのは、アプリが、攻撃者が操れる文字列から正規表現を組み立てるときだけです。たとえば、Regexp.new・Regexp.union・Regexp.compile に渡す形や、/#{input}/ のように正規表現の中に埋め込む形です。自分たちの開発者が書いた正規表現だけを使うアプリは、当たりません」です。

条件の言葉は、告知のとおり「攻撃者が操れる文字列」です。言い換えずに、このまま使います。例の4つの形は「たとえば」で挙げられたもので、これで全部だとは書かれていません。

自分のアプリに当てはめる例として、告知は GitLab の場合を書いています。GitLab は、利用者が書く CI の設定の中のパターンを Regexp.new で組み立てていました。自分のアプリでも、正規表現を作る文字列を攻撃者が操れるかを考えます。

出典: Ruby: Regexp compilation fixes related to GitLab's CVEs（英語）

自分のコードの候補を grep で探す

告知の4つの形を、自分のコードから探すコマンドです。app と lib のフォルダを探す例で、無害な値だけの見本のファイル（Regexp.new(params[:q])、Regexp.union(words)、/#{name}/i、/#{Regexp.escape(name)}/、"/users/#{id}"、Regexp.compile(tag)、変数を使わない正規表現の行など）で流しました。

$ grep -rnE "Regexp\.(new|union|compile)" app lib
app/models/search.rb:5:    Regexp.new(params[:q])
app/models/search.rb:9:    Regexp.union(words)
lib/tag.rb:3:    Regexp.compile(tag)
$ grep -rnF "/#{" app lib
app/models/search.rb:13:    /#{name}/i
app/models/search.rb:17:    /#{Regexp.escape(name)}/
app/models/search.rb:21:    "/users/#{id}"

grep は、読む行を絞るだけです。 上の出力にも、正規表現ではない普通の文字列（21行目の "/users/#{id}"）と、Regexp.escape を通した行（17行目）が出ています。出た行で、その文字列を攻撃者が操れるかを、人が読んで決めます。見つからなければ、何も出ません（終了コードは 1 です）。

何も出なくても、当たらないとは決まりません。告知の4つの形は「たとえば」で挙げられたもので、全部ではないからです。%r{…} の書き方は、告知の例にはありません。告知は、依存の gem について書いていません。

このコマンドは、Mac の grep で流しました。Linux と Windows では流していません。

Rails を使っている人は？

10月24日14時56分ごろに見た範囲では、Rails の側から、この件の告知は出ていません。Rails のセキュリティの告知の欄の最新は2026年7月31日で、10月23日の Rails の週報にも、Ruby 4.0.9 などの語はありません。Rails だから当たる、当たらない、ではなく、上の条件で自分のアプリのコードを見て決めます。

Rails 8.1.4 が要る Ruby は 3.2.0 以上です（2026年10月3日に見た値）。だから、3.3.13・3.4.12・4.0.9 のどれでも、Rails 8.1.4 の条件は満たします。Rails の N+1 の記事は、Rails 8.1.4 で書きました。

出典: Rails のセキュリティの告知の欄・This week in Rails（10月23日）

上げる版と、系統

上げる版は、4.0.9・3.4.12・3.3.13 以降です。系統ごとに、直しがどの版で入ったかが違います。

4.0.9・3.4.12・3.3.13 なら、直しが全部入っている

告知は、「当たる版」の見出しを立てていません。直しごとに、各系統で最初に入った版を並べた表を出しています。

それぞれの直しが、系統ごとに最初に入った版（告知の表）です。

直しの元の CVE	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	4.0.9	3.4.12	3.3.13

告知は、「4.0.9・3.4.12・3.3.13 には、これらの直しが全部入っている」と書いています。

4.0.9・3.4.12・3.3.13 より前は、直しの一部か全部が入っていません。4.0 系は直しごとに入った版が違うので、4.0.8 の人も、110264 の元の直しが入っていません。4.0 系は 4.0.9 に上げます。

出典: Ruby: Regexp compilation fixes related to GitLab's CVEs（英語）

系統ごとの支え（4.0・3.4・3.3・3.2 以前）

Ruby の公式サイトの「Branches」のページは、保守の段階を次のように書いています（日本語版のページで、段階の意味を確かめました）。

系統	段階	補足
4.0	通常保守	2025年12月25日に出た版
3.4	通常保守	2024年12月25日に出た版
3.3	セキュリティ保守	EOL は2027年3月31日の見込み（公式の言い方）
3.2	EOL（もう直しが出ない）	2026年4月1日に EOL

通常保守は不具合と脆弱性の直しを、セキュリティ保守は脆弱性の直しだけを、EOL（end-of-life、支えの終わり）はどんな直しも出さない段階です。ダウンロードのページのいまの安定版は 4.0.9 です。

3.2 以前について、10月23日の告知は何も書いていません。 当たるとも、当たらないとも書いていません。

Mac に最初から入っている Ruby（手元の macOS 14.4.1 では 2.6.10）は、Apple が、古いソフトとの互換のために入れていると書いています。この版が今回の不具合に当たるかは、告知に書かれていません。

出典: Ruby: 保守の段階（日本語）・Ruby: ダウンロード（日本語）・Apple: macOS Catalina のリリースノート

3.3.13 には resolv の直しも入っている

3.3.13 は、標準の gem の resolv（名前を引く部品）を 0.3.2 に上げました。これで、8月27日に告知された2件（CVE-2026-80212 と CVE-2026-80213）が直ります。CVSS 3.1 の点は、MITRE が付けたもので、80212 が 7.5、80213 が 4.0 です。

当たるのは、resolv で名前を引くコードだけです。Net::HTTP や TCPSocket の普通の接続は、OS の仕組みで名前を引くので当たらない、と8月27日の告知（日本語版があります）は書いています。依存の gem が resolv で名前を引く場合も含む、と告知は書いています。

手元の公式の Docker のイメージで、標準の gem の resolv の版を見た結果です。

$ gem list --local "^resolv$"
$ gem list --local "^resolv$"     # ruby:3.3.13-slim
resolv (default: 0.3.2)
$ gem list --local "^resolv$"     # ruby:3.4.12-slim
resolv (default: 0.7.2)
$ gem list --local "^resolv$"     # ruby:4.0.9-slim
resolv (default: 0.7.2)

詳しくは、8月27日の告知（日本語）を読んでください。

自分の Ruby の版を見る：ruby -v

ruby -v が、版を1行で出します。手元の公式の Docker のイメージ（slim）で流した結果です。

$ ruby -v     # ruby:4.0.9-slim
ruby 4.0.9 (2026-10-23 revision 3e93b23afc) +PRISM [aarch64-linux]
$ ruby -v     # ruby:3.4.12-slim
ruby 3.4.12 (2026-10-23 revision 366f5fdc00) +PRISM [aarch64-linux]
$ ruby -v     # ruby:3.3.13-slim
ruby 3.3.13 (2026-10-23 revision af48f08f21) [aarch64-linux]

出力の形は、「ruby 版 (日付 revision 番号) [機種]」です。4.0.9 と 3.4.12 には +PRISM が付きます。Bundler を使うアプリでは、bundle exec ruby -v が、その Gemfile のもとで動く Ruby の、同じ1行を出しました。

Mac に最初から入っている Ruby は、次のとおりでした（手元の macOS 14.4.1）。

$ which -a ruby
/usr/bin/ruby
$ ruby -v
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin23]

どうやって上げる？入れ方ごと

新しい版を入れられるようになった時刻は、入れ方ごとに違います。次の表の時刻は、新しい版を入れられるようになった時刻です（日本時間）。

入れ方	新しい版を入れられるようになった時刻
ruby-build（rbenv で使う）	10月23日13時47分（v20261023 に 4.0.9・3.4.12・3.3.13）
asdf（asdf-ruby）	10月23日15時47分（中で使う ruby-build を v20261023 に上げた）
mise	10月23日21時18分〜19分（組み立て済みの 4.0.9・3.4.12・3.3.13）
Homebrew	10月23日14時30分（`ruby` は 4.0.9、`ruby@3.4` は 3.4.12、`ruby@3.3` は 3.3.13。4.0.9 のビルド済みは15時45分）
Docker の公式イメージ	定義が10月24日1時33分に新しい版へ。Docker Hub のタグに最後に push されたのは10月24日4時57分〜5時2分
RubyInstaller（Windows）	10月24日5時33分〜39分（4.0.9-1・3.4.12-1・3.3.13-1）

入れ方ごとの上げ方です。

ruby-build（rbenv）: Homebrew で入れたなら brew upgrade ruby-build、git で入れたなら git -C "$(rbenv root)"/plugins/ruby-build pull です。そのあと rbenv install 4.0.9 などで入れ、rbenv global（この機械の既定）か rbenv local（このフォルダ。.ruby-version を作る、書き換える）で選びます
asdf: asdf plugin update ruby を流します。asdf-ruby は、新しい版を自分では取りに行かない、と書いているためです
mise: mise use ruby@4.0 で、4.0.x のいちばん新しい版になります。版を替えると gem は持ち越されないので、Bundler のアプリは mise exec -- bundle install を流します
Homebrew: brew upgrade ruby などです。名前を書くと、その式だけを上げます。ruby@3.2 は 3.2.11 のままで、「非推奨」の印が付いています
Docker の公式イメージ: タグ 4.0・3.4・3.3（4.0.9 なども）を取り直して、コンテナの中で ruby -v を見ます。10月24日14時49分ごろに見た定義には、3.2 の行はありません。表の「最後に push された時刻」は、最初に新しい版になった時刻ではありません
RubyInstaller: RubyInstaller の GitHub のリリースのページから入れます

rbenv install 4.0.9 などは、手元で流していないので、出力は載せません。上げたあとは、ruby -v で版を見ます（→「自分の Ruby の版を見る：ruby -v」）。

出典: ruby-build v20261023・ruby-build の入れ方と上げ方・rbenv: Ruby の版の入れ方・asdf-ruby・mise: Ruby・jdx/ruby のリリース・Homebrew: ruby・ruby@3.4・ruby@3.3・ruby@3.2・Homebrew: brew upgrade の説明・Docker Hub: ruby・Docker の公式イメージの定義・RubyInstaller のリリース

Gemfile に ruby の版を書いているとき

Gemfile に ruby "3.3.12" のように版を書いたままだと、3.3.13 に上げると bundle install が止まりました。公式の 3.3.13 のイメージに、次の Gemfile を置いて手元で試した結果です。

$ cat Gemfile
source "https://rubygems.org"
ruby "3.3.12"
$ bundle install --local
Your Ruby version is 3.3.13, but your Gemfile specified 3.3.12

Gemfile の行を新しい版に直します。または、ruby file: ".ruby-version" と書いて、.ruby-version から版を読ませる方法もある、と Bundler の文書は書いています。

出典: RubyGems Guides: Gemfile

OS の Ruby（apt）を使っている人は？

2026年10月24日14時52分から15時ごろ（日本時間）に見た範囲では、次のとおりでした。

Debian の追跡は、89078 と 110264 のページを「Debian の対象外: GitLab」と書いています（93577 と 97229 のページは開いていません）。ruby3.3 のページの未解決の一覧に、この件の行はありません
Ubuntu の CVE の追跡は、97229 を gitlab のパッケージだけの行にしています。110264 は、追跡にありません（89078 と 93577 の追跡は、時間切れで見られませんでした）
Ubuntu の Ruby の告知（USN）の最新は2026年7月16日で、Ubuntu の Ruby のパッケージの公開も、10月23日より後にはありません

Ruby の CVE が無いので、OS の追跡には Ruby の行がありません。今回の直しが OS の Ruby に入ったかを、追跡のページで確かめることはできません。

いま配られている版は、次のとおりです。これは配られている版で、直ったかどうかの印ではありません。

OS	パッケージ	配られている版
Debian 13	ruby3.3	3.3.8-2
Debian 12	ruby3.1	3.1.2-7+deb12u1
Ubuntu 24.04	ruby3.2	3.2.3-1ubuntu0.24.04.8
Ubuntu 26.04	ruby3.3	3.3.8-2ubuntu3.1
Ubuntu 26.10	ruby3.3	3.3.8-2.2ubuntu4

取れる道は、次の2つです。順番に意味はありません。

公式の版の Ruby を、ruby-build などで入れる（→「どうやって上げる？入れ方ごと」）
配布元（Debian・Ubuntu）の告知を待つ（記事で開いた Debian の追跡の ruby3.3 のページを開き直す）

どちらの道でも、信用できない入力から正規表現を組み立てない、という告知の言い方は、同じように効きます。

出典: Debian の追跡（CVE-2026-89078・CVE-2026-110264・ruby3.3・ruby3.1）・Ubuntu: CVE-2026-97229

すぐ上げられないときは？

告知は、次のように書いています。

If you cannot upgrade, please avoid compiling regular expressions from untrusted input.

訳すと、「上げられないなら、信用できない入力から正規表現を組み立てるのを避けてください」です。

そして、Regexp.timeout については、次のように書いています。

Regexp.timeout does not protect against these bugs. Limiting the length of patterns does not reliably protect against them either, because some of them can be triggered by short patterns.

訳すと、「Regexp.timeout は、これらの不具合を防げません。パターンの長さを絞っても、確かには防げません。短いパターンで起きるものもあるからです」です。理由が書かれているのは、長さの制限の方だけです。

これは、上げるまでのつなぎです。上げるのが先です。

出典: Ruby: Regexp compilation fixes related to GitLab's CVEs（英語）

悪用はされている？（2026年10月24日時点）

2026年10月24日14時47分から15時ごろ（日本時間）に見た範囲では、悪用が確かめられた、という文は、見つかりませんでした。

出どころ	確かめたこと
CISA の KEV（悪用が確認された脆弱性の一覧）	版 2026.10.23（1756件）に、GitLab の4つも、resolv の2つも載っていません
CISA が CVE の記録に付けた「悪用の状況」（SSVC の Exploitation の欄）	GitLab の4つとも none（なし）。resolv の2つも none
JPCERT/CC	注意喚起の一覧（最終更新は10月23日）に、今回の Ruby と GitLab の件はありません
IPA	「重要なセキュリティ情報」の2026年の一覧に、10月の Ruby の項はありません
JVN	トップページに、Ruby と Onigmo の項はありません（JVN iPedia は、サービス停止中で検索できませんでした）
Ruby の告知	10月23日の告知と、4.0.9・3.4.12・3.3.13 の3つの告知に、悪用の文はありません

JPCERT/CC の Weekly Report（2026年10月21日号）は、GitLab の CVE-2026-97229 について、PoC（弱点が本当にあることを示すための試しのコード）が公開されていることを確認している、と書いています。この文は GitLab の製品についての文で、ほかの Ruby のアプリについては書いていません。PoC の置き場所は、この記事には書きません。

PoC は悪用に数えません。そして、KEV に無いことは、悪用されていない証明ではありません。脆弱性の知らせの読み方にあるとおりです。上に書いたのは、この時刻までに見つかった範囲です。

悪用が確かめられていても、いなくても、やることは同じです。上げます（→「上げる版と、系統」）。

出典: CISA: KEV の一覧のページ・CVE の記録（CVE-2026-89078・CVE-2026-93577・CVE-2026-97229・CVE-2026-110264・CVE-2026-80212・CVE-2026-80213）・JPCERT/CC: Weekly Report 2026-10-21・JPCERT/CC: 注意喚起の一覧（2026年）・IPA: 重要なセキュリティ情報（2026年）・JVN

よくある質問

Regexp.timeout を設定しています。それで足りますか？

足りません。告知は、「Regexp.timeout では防げない」と書いています（→「すぐ上げられないときは？」）。

Regexp.escape を通しています。当たりませんか？

10月23日の告知には、Regexp.escape の話はありません。告知が書く手立ては、上げることと、上げられないなら信用できない入力から正規表現を組み立てないことです。

Rails のアプリは当たりますか？

Rails だから当たる、当たらない、ではなく、告知の条件で決まります。10月24日14時56分ごろに見た範囲では、Rails の側の告知は出ていません（→「Rails を使っている人は？」）。

Mac に最初から入っている Ruby（2.6）は？

告知は、3.2 以前に触れていません。2.6 は、2022年4月12日に支えが終わっています（Ruby の「Branches」のページ）。Apple は、macOS Catalina のリリースノートで、先の macOS では既定で入らなくなる、と書いています。

セキュリティの検査の道具では、どの番号で追えばいいですか？

告知は、GitLab の番号（4つ）を使うよう書いています。Ruby は、Ruby として CVE を求めていない（少なくとも今は）、と告知は書いています。

自分の Ruby で確かめること（チェックリスト）

ruby -v（Bundler のアプリは bundle exec ruby -v）で、自分の系統の 4.0.9・3.4.12・3.3.13 以上か見る（→「自分の Ruby の版を見る：ruby -v」）（apt で入れた OS の Ruby は、版の番号では直ったか分かりません（→「OS の Ruby（apt）を使っている人は？」））
自分のコードで4つの形を grep で探し、出た行の文字列を攻撃者が操れるかを読む。何も出なくても、版は上げる（→「自分のコードの候補を grep で探す」）
入れ方に合った道具で上げる。Gemfile の ruby の行も直す（→「どうやって上げる？入れ方ごと」）
OS の Ruby を使っているなら、2つの道のどちらにするか決める（→「OS の Ruby（apt）を使っている人は？」）
上げられない間は、信用できない入力から正規表現を組み立てない。Regexp.timeout に頼らない（→「すぐ上げられないときは？」）
3.3 を使っているなら、resolv も 0.3.2 になったか見る（→「3.3.13 には resolv の直しも入っている」）

まとめ

10月23日の Ruby 4.0.9・3.4.12・3.3.13 は、正規表現の部品 Onigmo の不具合の直しを含む。GitLab が付けた4つの CVE（89078・93577・97229・110264）の元の不具合で、Ruby 自身は CVE を求めていない（少なくとも今は）、と告知は書いている
点数（9.9・10.0）は、GitLab が GitLab の製品に付けた CVSS 3.1 の点。10月24日時点で、Ruby に付いた点は無い
当たるのは、攻撃者が操れる文字列から正規表現を組み立てるアプリだけ。Regexp.new・Regexp.union・Regexp.compile と /#{input}/ が例。自分たちの開発者が書いた正規表現だけを使うアプリは当たらない
上げる版は 4.0.9・3.4.12・3.3.13 以降。上げられないなら、信用できない入力から正規表現を組み立てない。Regexp.timeout では防げない
自分の版は ruby -v で見る。Gemfile の ruby の行が古い版のままだと、上げたあとに bundle install が止まる
OS の Ruby は、10月24日15時ごろに見た範囲では、追跡のページで直ったかを確かめられない
悪用は、2026年10月24日15時ごろまでに確かめた範囲では、確認の文が見つからなかった。ただし、KEV に無いことは、悪用されていない証明ではない
この記事で確かめていないこと：Regexp.escape を通したコード、%r{…} の書き方、依存の gem のコードが当たるか、3.2 以前が当たるか、OS の Ruby に直しが入るか、Ubuntu の 89078・93577・80212 の追跡（時間切れで見られなかった）、Ubuntu 22.04・RHEL・Alpine、JVN iPedia の項、mise・asdf・Homebrew の上げ方を手元で流した結果、GitLab を自分で動かしている人の上げ方