GitLabの穴は、Rubyの正規表現の中にあった。利用者の入力から正規表現を作るアプリは更新を

• Rubyの正規表現エンジン「Onigmo」の不具合で、細工した正規表現を渡すとメモリが壊れ、遠隔からプログラムを動かされるおそれがあった
• 見つけたのはGitLab。GitLab側では深刻度10.0（最高）、ログイン不要の脆弱性として修正済み
• Rubyは4.0.9 / 3.4.12 / 3.3.13で修正。ただしRuby自身はCVE番号を取っていないため、スキャナーで見落とすおそれがある

プログラミング言語Rubyの開発チームが、10月23日（協定世界時）にRuby 4.0.9、3.4.12、3.3.13を公開した。直したのは、Rubyに組み込まれている正規表現のエンジン「Onigmo」の不具合だ。

この不具合を見つけて報告したのは、ソースコード管理サービスのGitLabだった。GitLabの中で、外から遠隔でプログラムを動かされる穴になっていたという。

今週このサイトでは、PHPの重大な脆弱性を追ってきた。今度はRubyだ。ただ、今回は話の形がかなり違う。

何が起きていたか

正規表現は、「数字が3つ続く」「aかbで始まる」のような文字の並びのパターンを書く方法だ。検索や入力チェックで広く使われている。

Rubyは正規表現を使う前に、それを内部で扱える形に組み立てる（コンパイルする）。Ruby公式によると、特別に細工した正規表現を渡すと、この組み立ての途中でメモリが壊れる不具合が複数あった。

メモリが壊れると、うまく細工すれば攻撃者が用意したプログラムを動かせることがある。GitLabはそこまで持っていけることを確かめた。

GitLabでは「深刻度10.0」

GitLabは、利用者が書いた正規表現を受け付ける。たとえばCI（自動テストや自動公開）の設定の中に、正規表現でブランチ名などを指定できる。それをRubyの Regexp.new で組み立てていた。

GitLabの公表によると、深刻度は次のとおりだ。

• CVE-2026-89078：ログインした利用者が、CIの設定に書いた正規表現でサーバー上のプログラムを動かせる。CVSS 9.9。9月23日の19.4.1などで修正
• CVE-2026-110264：ログインしていない人でも、条件によってはサーバー上のプログラムを動かせる。CVSS 10.0。GitLab 7.0以降のすべての版が対象で、10月21日の19.5.1などで修正

GitLabは、自社が配る製品に同梱しているRubyに先に修正を入れて、対応を済ませていた。今回、その修正がRuby本体にも入ったという流れだ。

GitLab.comはすでに修正済みだ。自社のサーバーでGitLabを動かしているところは、GitLabの最新の修正版に上げる必要がある。

Rubyで作ったアプリは影響を受けるか

Ruby公式は、影響を受ける条件をはっきり書いている。

この不具合に届くのは、攻撃者が操作できる文字列から正規表現を組み立てるアプリケーションだけだ。たとえば Regexp.new、Regexp.union、Regexp.compile に渡す場合や、/#{input}/ のように正規表現の中に埋め込む場合。開発者が自分で書いた正規表現だけを使うアプリは影響を受けない。

つまり、問題になるのは「利用者に正規表現を書かせる機能」や、利用者の入力をそのまま正規表現に混ぜている箇所だ。検索の絞り込み、入力ルールの設定画面、ログの抽出などで、ありうる作りだ。

時間制限や長さ制限では防げない

これまで、利用者の正規表現を受け付けるときの注意は、主に「処理が終わらなくなる」攻撃（ReDoS）への対策だった。Rubyにも Regexp.timeout という時間制限の仕組みがある。

だがRuby公式は、時間制限はこの不具合には効かないと書いている。パターンの長さを制限しても確実ではない。短いパターンで起きるものもあるからだ。

やること

1. Rubyを4.0.9、3.4.12、3.3.13以降に上げる
2. すぐ上げられないなら、信頼できない入力から正規表現を組み立てない
3. 自分のコードに該当箇所があるか探す。たとえば次のように検索できる

grep -rnE "Regexp[.](new|union|compile)|/#[{]" app lib

見つかった箇所で、中に入る文字列が利用者から来るかを確かめる。Regexp.escape を通してから組み立てている場合は、利用者がパターンの形を指定できないので、この条件からは外れると考えられる（ここは筆者の見方）。

なお、今回の告知に入っているのは4.0・3.4・3.3の3系列だ。3.3は、通常は脆弱性の修正だけを出す段階だが、今回は例外として入れたという。それより古い系列は、この修正の対象として挙がっていない。

Rubyは「脆弱性」とまだ決めていない

今回いちばん珍しいのは、ここだ。

Ruby公式は、この修正についてRubyとしてのCVE番号を申請していない。理由も書いている。

• Rubyはもともと、信頼できない入力から正規表現を作って使うのは安全ではないという立場だった
• 一方で、今の公式ドキュメントは、信頼できない正規表現について「処理が終わらなくなる」問題しか書いていない。それを使ってよいのかどうかは、はっきり書いていなかった
• 過去に似た不具合（2022年と2024年）は、検討のうえで脆弱性として扱った
• 今回は、ドキュメントをどう書くか、脆弱性として扱うかを、これから話し合う

実務で困るのは、脆弱性スキャナーだ。スキャナーは、使っているソフトの版とCVE番号を突き合わせて警告を出す。Rubyとして番号がないと、Rubyの版を見ても警告が出ないおそれがある。

Ruby公式は、当面はGitLabのCVE番号（上の4つ）で追うよう案内している。

「仕様」と「穴」のあいだ

ここからは筆者の見方だ。

「危ない使い方をしたほうが悪い」と言えば、それまでだ。だが、ドキュメントに書いていない危険は、使う側には分からない。現にGitLabほどの規模の製品が、その使い方をしていた。

Rubyが「これから決める」と正直に書いているのは、誠実だと思う。使う側としては、決まるのを待たずに上げておくのがいちばん早い。

PHPの「鬼車」とは別物

名前が似ているので補足しておく。OnigmoはRubyのためのエンジンで、鬼車（Oniguruma）から分かれて作られたものだ。PHPの文字列処理（mbstring）などが使っているのは鬼車のほうで、今回の告知はRubyのOnigmoについてのものだ。

まとめ

• Rubyの正規表現エンジンOnigmoに、細工したパターンでメモリが壊れる不具合
• GitLabでは遠隔からプログラムを動かせる穴になった。最大でCVSS 10.0、ログイン不要
• 影響するのは利用者の入力から正規表現を組み立てるアプリ。自分で書いた正規表現だけなら影響しない
• 時間制限や長さ制限では防げない。Rubyを4.0.9 / 3.4.12 / 3.3.13以降へ
• RubyとしてのCVEはまだ無い。スキャナーではGitLabのCVE番号で追う

出典

• Ruby「Regexp compilation fixes related to GitLab’s CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264」（2026年10月23日。不具合の内容、影響を受ける条件、推奨対応、CVEについての方針。引用の日本語は筆者による訳）
• Ruby「Ruby 3.3.13 Released」（3.3系に例外として修正を入れたこと）
• GitLab「Critical Patch Release: 19.5.1」（CVE-2026-110264、CVSS 10.0、影響する版）
• GitLab「Critical Patch Release: 19.4.1」（CVE-2026-89078、CVSS 9.9）
• 窓の杜「『Ruby』の正規表現エンジン『Onigmo』にリモートコード実行の問題、セキュリティ更新を実施」（2026年10月23日）

本記事は2026年10月24日時点の公式発表に基づく。Rubyが今後CVEを申請した場合などは、公式の告知が更新される。自社のアプリが影響を受けるかは、コードを確認したうえで判断すること。