正規表現脆弱性をAIで検出──攻撃者制御パターンのリスクを事前に防ぐ方法

なぜいま、正規表現の脆弱性が深刻なのか

2026年10月23日、Rubyコアチームは正規表現エンジンOnigmoに存在する3つのメモリ安全性バグを修正するセキュリティアップデート（Ruby 4.0.9 / 3.4.12 / 3.3.13）をリリースした（出典：glitchwire.com、lilting channel）。修正されたバグは、交替演算子後のdouble-free、サイズ計算時の整数オーバーフロー、繰り返し量指定子処理での符号付き16bit整数オーバーフローによる範囲外書き込みの3件である。

今回の脆弱性で特筆すべきは、影響のトリガーが「外部入力から正規表現をコンパイルする」という一行のコードにある点だ。Regexp.new(input)、Regexp.union(params)、あるいは/#{input}/のように、ユーザー入力や外部データをそのままパターンとして渡す実装が存在する場合、攻撃者はOnigmoのパーサーを標的にした細工済みパターンを送り込むことができる（glitchwire.com、lilting channel）。開発者自身が記述した静的なパターンのみを使うアプリケーションには影響がない。

研究者Johan Carlsson（ハンドル：joaxcar）がHackerOneバグバウンティ経由で報告したGitLab関連の4件のCVEのうち、2026年10月12日開示のCVE-2026-97229と10月21日開示のCVE-2026-110264はCVSSスコア10.0かつ認証不要の最高深刻度と評価されている。残る2件（CVE-2026-89078、CVE-2026-93577。9月23日開示）はCVSS 9.9でログインが必要であり、4件すべてが10.0というわけではない（thehackernews.com、bitnewsbot.com、glitchwire.com）。CVE-2026-110264はGitLab 7.0以降の全バージョンに影響する（DEV Community）。

しかしこの問題はGitLabやRubyだけの話ではない。外部入力を正規表現エンジンに渡すという脆弱パターンはPython、JavaScript、Javaなど広範な言語環境に潜在する構造的な課題だ。コードレビューで見落とされやすく、テストでも攻撃的な入力を網羅しにくい。本稿では、この種のリスクをAIを活用して早期に発見・抑止するための実務的なアプローチを整理する。

こうした脆弱性が実際の攻撃でどんな被害を生んでいるかは、AIハッキングによる日本・世界の主な被害一覧で説明しています。

関連記事AIによる情報漏洩の原因・経路は？

正規表現脆弱性の構造：なぜ見落とされるのか

正規表現に関連する脆弱性は大きく2種類に分類できる。ひとつは今回のOnigmoのようなエンジン自体のメモリ安全性バグ、もうひとつはReDoS（正規表現サービス拒否）に代表される脆弱なパターン設計に起因する問題だ。

前者はエンジンバージョンの管理が不十分な環境で顕在化する。アプリケーション依存ライブラリのバージョン管理には注意を払う開発チームも、言語ランタイム自体の定期アップグレードは後回しになりがちだ。Ruby 3.2以前は2026年4月1日にEOLを迎えており、修正バックポートが提供されないため、古いバージョンを継続使用するリスクは無視できない（bitnewsbot.com）。

後者のReDoSは、バックトラックが指数関数的に爆発する構造を持つパターン（例：(a+)+）に長い文字列を入力した際に発生するサービス拒否の一形態だ。パターンの書き方の問題であり、エンジンのバグではない。開発者が意図せず書いてしまうケースが多く、コードレビューだけでは見つけにくい。

両者に共通する見落としの構造的な原因として、以下が挙げられる。

• 正規表現は「動けばよい」という意識から、セキュリティ観点のレビューが省略されやすい
• 自動テストは機能的な正当性を検証するが、脆弱なパターンへの攻撃的入力を網羅しない
• エンジンのバージョンアップは機能追加を伴わないため、優先度が下がる
• コードベースに散在する正規表現のうち、どこで外部入力を受け取っているかの全体把握が難しい

AIで正規表現の脆弱性を検出する：3つのアプローチ

未然に防ぐ：静的解析AIによるコードレビュー支援

コードベースに外部入力を受け取る正規表現が潜んでいるかどうかを、人間の目だけで把握するのは規模が大きくなるほど困難になる。AIを活用した静的解析ツールはこの課題に直接対応する。

• データフロー解析の自動化：GitHub CopilotやAmazon Q Developer（旧Amazon CodeWhisperer）のようなAI支援コーディングツールは、ユーザー入力がどの変数を経由して正規表現コンパイル呼び出しに到達するかをコンテキストとして把握し、リスクのある実装パターンをフラグ付きで示唆できる。
• ReDoS検出ツールとの統合：vuln-regex-detectorやredos-detectorといった静的ツールは、バックトラック爆発が起きうる脆弱パターンを自動検出する。CIパイプラインに組み込むことで、プルリクエスト単位でパターンの安全性を確認できる。
• LLMによるパターンレビュー：コードレビューの補助として、LLMに「このパターンに攻撃的な入力が渡された場合の挙動」を問い合わせる使い方は、人間のレビュアーが見落とす脆弱な量指定子の組み合わせを指摘させる場面で有効だ。ただしLLMの出力は必ず人間が検証することが前提となる。

今回のOnigmoバグでいえば、繰り返し量指定子を多用した複雑なパターンが外部から渡される経路がないかをコードベース全体で検索・フラグするプロセスは、AI支援なしでは現実的に難しい規模のリポジトリが多い。

早く見つける：依存関係監視とパッチ適用の自動化

今回のRubyパッチが示すもうひとつの教訓は、エンジン層のバグは公開後の対応速度が重要だという点だ。Ruby 4.0.8はパッチが出た時点で一部修正が未適用であり、4.0.9への正確なアップグレードが必要だった（bitnewsbot.com）。

• Dependabot（GitHub Actions統合）：言語ランタイムを含む依存関係の脆弱性情報を監視し、パッチバージョンへのアップグレードPRを自動生成する。GitHubリポジトリに対してはゼロ設定で利用開始できる。
• Snyk / FOSSA：コンテナ・CI/CDパイプライン内のライブラリスキャンをAIで優先度付けし、CVSSスコアとビジネス影響を組み合わせた修正優先順位を提示する。
• OpenSSF Scorecard：リポジトリのセキュリティ衛生状態をスコアリングし、言語バージョンの陳腐化やパッチ対応の遅延を定量的に可視化する。

Ruby 3.2以前はすでにEOLのため、これらのツールが古いランタイムバージョンをフラグしても修正バックポートは存在しない。この場合、ツールの警告を受けてRuby 3.4または4.0系への移行計画を立てることが実質的な対応となる（bitnewsbot.com）。

被害を小さくする：外部入力の正規表現コンパイルを制御する

即時アップグレードが困難な本番環境では、リスクを最小化するための緩和措置が必要になる。注意すべきは、Regexp.timeoutの設定やパターン長の制限は今回の脆弱性への対策にならないという点だ。これらのバグはパターンの実行時ではなくコンパイル時に発動するためである（lilting channel）。

有効な緩和策は、外部入力から正規表現をコンパイルするコードパスを特定し、そこへの入力を停止または厳格に検証することだ。AIツールを活用した緩和アプローチとしては以下が考えられる。

• WAF（Webアプリケーションファイアウォール）のルール自動生成：ModSecurityやAWS WAFにおいて、AI機能を備えた製品では、異常な入力パターンを検知して遮断するルールを自動適用できる場合がある。今回のバグを確実に防げる保証はなく、あくまで緩和策にとどまる。
• 入力バリデーションの強化：エンドポイントで受け取ったユーザー入力を正規表現コンパイル前に制限するロジックを、AIコードアシスタントを使って網羅的にコードレビューし、見落としを減らす。

誰に、どのような場面で役立つか

今回の脆弱性と、AIを使った対応策は、以下のような現場に直接関係する。

• Rubyアプリケーション開発チーム：自社サービスがRegexp.newやRegexp.unionで外部入力を処理しているかどうかをまず確認する必要がある。GitLabを含むRails系のアプリケーションは特に確認対象となる。
• 自治体・公共機関のシステム担当者：オープンソースのCMSやポータルシステムにRubyが使われているケースがある。ベンダー任せにせず、利用しているシステムのRubyバージョンとパッチ状況を確認するプロセスを設けることが推奨される。
• SaaS・マルチテナント環境の運用者：検索フィルターや入力フォームでユーザー定義の正規表現を受け取る機能がある場合、今回の攻撃ベクターに直接該当する可能性がある。
• セキュリティ担当者・開発プロセス設計者：CIパイプラインにReDoSスキャナーや依存関係監視ツールを組み込む際の根拠として、今回のような事例が技術的な説明材料になる。

主要ツールの対応領域比較

ツール・アプローチ	主な対応領域	エンジンバグ検出	ReDoS検出	自動パッチ提案	CI/CD統合
Dependabot	依存関係・ランタイム監視	○（CVE追跡）	×	○	○
Snyk	依存関係・コードスキャン	○	△	○	○
vuln-regex-detector / redos-detector	ReDoSパターン検出	×	○	×	○
AI支援コードレビュー（Copilot等）	データフロー・パターン設計	△	△	△（提案のみ）	△
WAF（AI機能付き）	ランタイム入力制御	△（緩和のみ）	△	×	○
OpenSSF Scorecard	セキュリティ衛生状態評価	△（バージョン陳腐化）	×	×	○

○＝主要対応 △＝部分的対応 ×＝対応外

AIでは解決できないこと：注意点と限界

最終判断は必ず人間が行う。AIが出力するコードレビュー結果や脆弱性フラグは、誤検知（false positive）と見逃し（false negative）の両方が発生する。特にデータフロー解析は、複雑な間接参照やシリアライズを経由する経路では精度が低下しやすい。AIの指摘は調査の起点として扱い、最終的なリスク判断はセキュリティエンジニアが行う体制が必要だ。

ゼロデイには対応できない。今回の3バグのように、パッチが出るまで一般に非公開だった脆弱性を事前に検出することは、AIを含むいかなる静的解析ツールも原則としてできない。最善の防御は、エンジン側のバグへの依存を最小化する設計（外部入力から動的に正規表現を生成しない）を採用することだ。

監視コストとプライバシーのトレードオフ。依存関係監視やWAFのログ解析にAIを活用すると、コードベースや通信ログの外部サービスへの送信が発生する場合がある。個人情報や機密情報を含む可能性のあるログをAIクラウドサービスに渡す際は、組織のデータ取り扱いポリシーおよび個人情報保護法の要件と整合しているかを事前に確認する必要がある。

ツールが示す優先度は参考情報に過ぎない。依存関係監視ツールがパッチ適用を提案しても、テスト環境のないシステムでの本番適用には人間によるリスク判断と動作検証が不可欠だ。ツールの優先度スコアは組織の運用文脈に合わせた判断を代替するものではない。

明日から試せる実務的な一歩

今回の事例を受けて、開発チームが明日から着手できる具体的な行動を以下に整理する。

1. Rubyバージョンの確認とアップグレード：本番・ステージング環境のRubyバージョンを確認し、4.0系は4.0.9、3.4系は3.4.12、3.3系は3.3.13へアップグレードする。3.2以前を使用している場合は3.4または4.0系への移行計画を立てる（bitnewsbot.com）。
2. Regexp.new / Regexp.union / Regexp.compileの使用箇所の全列挙：grep -rn "Regexp\.\(new\|union\|compile\)\|\/#{" . 等でコードベースを検索し、外部入力を引数に取っている箇所を特定する。
3. DependabotまたはSnykのCIへの導入：GitHubリポジトリであればDependabotのセキュリティアップデートを有効化し、今後の言語ランタイムパッチを自動検知する仕組みを設ける。
4. vuln-regex-detectorなどReDoS検出ツールのCIへの組み込み：正規表現パターンを含むコードの変更に対して自動スキャンを走らせ、ReDoS脆弱パターンをマージ前に検知するステップを追加する。
5. 外部入力からの動的パターン生成の設計見直し：ユーザーが正規表現パターンを入力できる機能が存在する場合、それが本当に必要かを再評価する。固定パターンへのマッピングや、サニタイズ済み文字列検索への置き換えを検討する。

セキュリティ対応の基本は、エンジン層のバグへの依存そのものを減らす設計と、パッチ情報の自動追跡の仕組みを組み合わせることにある。AIツールはこのプロセスの効率を高める補助手段として機能するが、組織として定期的に見直す運用プロセスの構築が前提となる。

---

参考文献

• glitchwire.com https://glitchwire.com/news/ruby-patches-onigmo-regex-bugs-that-let-attackers-own-gitlab-servers-without-log/
• lilting channel https://lilting.ch/en/articles/ruby-regexp-onigmo-fixes-gitlab-cves
• DEV Community https://dev.to/hacksgr/ruby-language-releases-new-versions-to-fix-serious-security-flaws-1p3m
• bitnewsbot.com https://bitnewsbot.com/ruby-patches-critical-regex-flaws-after-gitlab/