COSCUP 2026 | 聊聊 Ruby 的 ReDoS 防禦：吃瓜設計權衡、整合 Rails 實踐、窺探 Regexp 未來動向

「每次提起升版就被已讀。」

Ruby 3.2 導入了重要的 Regexp 更新，而隨著 Ruby 4 發佈，Ruby 3.2 也正式進入 EOL。近年的 Ruby Regexp 改善，也讓 ReDoS 的防禦逐漸從「怎麼寫 Regex」延伸到「底層如何幫開發者收斂風險」。

然而， 2026 年初 GitLab 的 CVE-2026-1388，以及 Active Support 的 CVE-2026-33169，也再次提醒我們：在複雜的 Web 應用實作中，Regexp 仍然可能成為效能與安全問題的入口。

這場演講會延續 RubyJam 3 月 Meetup 中對 Ruby Feature #17837 與 #19104 的設計權衡討論，並加入 2026 年最新的技術動態：

1. 案例拆解：分析 ReDoS CVE 案例，看看在現有防護機制下，哪些模式依然可能帶來風險。
2. Rails 實踐：說明如何在 Rails 應用程式中整合 Regexp Timeout。
3. 從 ReDoS 延伸到 Timing Attack：回應 RubyJam Meetup 的現場提問，聊聊演算法複雜度攻擊的另一面，以及 Ruby 生態系中如何實作 Constant Time Comparison。
4. Ruby Regexp 的最新方向：分享來自 RubyKaigi 2026 的第一手資訊，看看 Regexp 導入 JIT 的進展，以及對安全性議題的可能影響。

• COSCUP 2026 官網： https://coscup.org/2026/session/FYSGQ8

---

Diving into Ruby's ReDoS Defense: Design Trade-offs, Rails Integration, and the Future of Regexp

"Left on read... every time I suggest a version upgrade."

Ruby 3.2 introduced significant improvements to Regexp security and performance. With Ruby 4 recently released and Ruby 3.2 now officially reaching EOL, the community’s approach to ReDoS (Regular Expression Denial of Service) has gradually extended from “how do we write safe Regex” to “how can the runtime itself help reduce risk for developers.”

However, the CVE-2026-1388 incident in GitLab and CVE-2026-33169 in Active Support in early 2026 once again remind us that in real-world web applications, Regexp can still become an unexpected source of performance and security issues.

This talk continues the discussion from the RubyJam 2026.03 Meetup around Ruby Feature #17837 and #19104, and extends it with the latest developments in 2026:

1. Case breakdown: Analyzing two ReDoS-related CVEs, and examining which Regexp patterns can still introduce risk under existing mitigation mechanisms.
2. Rails in practice: How to integrate Regexp Timeout into Rails applications, and what practical pitfalls to watch out for.
3. From ReDoS to Timing Attacks: Following up on questions from the RubyJam Meetup, exploring the other side of algorithmic complexity attacks, and how Ruby ecosystems implement Constant Time Comparison.
4. The latest direction of Ruby Regexp: First-hand insights from RubyKaigi 2026, looking into the ongoing progress of introducing JIT into Regexp and what it may imply for security considerations going forward.

• COSCUP 2026 Official Website: https://coscup.org/2026/en/session/FYSGQ8

Transcript

1. $ time ruby -e '/^😈*升?😈*$/.match?(' \ -e '"😈" * 20268 + "談談 Ruby 的 ReDoS 防禦設計 ")' Speaker.find_by(name: 'Kasa') Date.new(2026, 8, 9) 1
2. $ time ruby -e '/^😈*升?😈*$/.match?(' \ -e '"😈" * 20268 + "談談 Ruby 的 ReDoS 防禦設計 ")' 🐢 🐇 2
3. $ time ruby -e '/^(\w+|😈+)*$/.match?(' \ -e '"😈" * 20268 + "談談 Ruby 的 ReDoS 防禦設計")' 😨 🐇 3
4. 👋 self.inspect ☂ Kasa @k_hno3 💼 NTU COOL # EdTech 💎 ['Ruby Taiwan Organizer'].push('RubyKaigi 2026 Helper') 🗣 [ :中文, :EN, :日本語 ] 🤖 [ :Ruby, :TypeScript, :Python ] 4
5. 👋 self.inspect ☂ Kasa @k_hno3 💼 NTU COOL # EdTech 💎 ['Ruby Taiwan Organizer'].push('RubyKaigi 2026 Helper') 🗣 [ :中文, :EN, :日本語 ] 🤖 [ :Ruby, :TypeScript, :Python ] # …偶爾也寫一點 ReactJS # …偶爾也弄一點 DevOps # …偶爾也碰一點 GPU 跑跑 self-host LLM & ASR 模型 # 看得出來專長就是 ...雜耍 + 纏鬥 🤡 …還 沒有點到資 安 今天就是個 好奇寶寶，拋磚引玉， 帶大家 吃瓜 Ruby 語言安全性發展 啦！ 請多多交流補充 󰚥 5
6. topics.each 😈 小惡魔的啓示：Backtracking 🍿 那 Ruby 怎麼應對呢？吃瓜！ #17837 Regexp Timeout #19104 Regexp#match Optimization 🔍 我也想小心，但人腦轉不過來啦，有沒有好用工具？ 🚨 還是有風險？！Rails 和 GitLab 的 CVE 案例 👀 延伸小聊：Timing Attack？ 󰝊 延伸小聊：來自 RubyKaigi 2026 的第一手 Regexp 未來動向！ 🤔 為什麼想在 2026 重提 ReDoS 議題 6
7. 😈 小惡魔的啓示：Regex Backtracking 7
8. 😈 小惡魔的啓示：Regex Backtracking 🔗 regex101.com /^😈*升?😈*$/.match?("😈😈😈已讀") 8
9. 😈 小惡魔的啓示：Regex Backtracking /^😈*升?😈*$/.match?("😈😈😈已讀") 因為想讓大家方便自己玩玩看，這邊用 regex101 現有的引擎呈現回溯，如果想觀察 Ruby 的 Onigmo 引擎行為，可以編譯時開 啟 DEBUG 設定，並印出 trace 賞玩！ 9
10. 😈 小惡魔的啓示：Regex Backtracking 今天先看一眼就好！有嫌疑的 Pattern 例子： 1. 巢狀量詞 與 重疊的分支 Nesting quantifiers and overlapping disjunctions ^(a)+$, ^(a|a)+$ ... 2. 有 量詞 的 重疊相鄰 Quantified overlapping adjacencies ^a+a+$, ^a+a+a+$ ... 3. 沒有 開頭錨點 No caret a+$ … 如想進一步瞭解 ...關鍵字 NFA https://rubykaigi.org/2023/presentations/lmt_swall ow.html 10
11. 🍿 那 Ruby 怎麼應對呢？吃瓜！ 11
12. 🍿 #17837 Regexp Timeout - 提案 🙋 ReDoS 是多年常見 的風險，我認為應該在 語言本身做一些防護設 計。 有一些手法可以透過安 裝外部工具實踐，但不 是所有的 Ruby runtime 都能簡單處理。 12
13. 🍿 #17837 Regexp Timeout - 發布功能 全域設定 針對特定 Regex 設定 13
14. 🍿 #17837 Regexp Timeout - 有趣的討論 [ 回溯次數派 Backtrack Limit ] 同一個 Ruby 版本(引擎實作) 的「回溯次數」是確定的，「時長」會受到 許多因素影響（eg. CPU 種類、CPU 當下負載） [ 超時派 Timeout ] 引擎的實作仍會有變，而使用者多是做 APP，對於自己服務「時長」的 需求會是更固定、直觀、好決定的。 → 核心：都希望讓使用者更容易訂出設定值、而且不用一直改 → 最後選 [超時派] 。 14
15. 🍿 #17837 Regexp Timeout - 社群的反應 Rails 8 預設 Regexp.timeout 為 1 秒 https://rubyonrails.org/2024/11/1/this-week-in-rails 15
16. 🍿 #17837 Regexp Timeout - 社群的反應 Rails 8 預設 Regexp.timeout 為 1 秒...那如果我還在 Rails 7 呢 16
17. 🍿 #17837 Regexp Timeout - 社群的反應 Rails 8 預設 Regexp.timeout 為 1 秒...那如果我還在 Rails 7 呢 其實 3.2.0~3.3.X 間，持續有 Regexp Timeout 控 制、記憶體洩漏 相關修復；我個人實測的經驗， 建議至少升級到 3.3.2 比較穩定喔！ 17
18. 🍿 #19104 Regexp#match Optimization - 提案 🙋 設定適當的 Timeout 值 很不容易。 太短可能會讓系統功能壞掉 ，太長又難以有效預防 ReDoS。 來用 Memoization 改善 Regexp#match 的速度 吧！ https://bugs.ruby-lang.org/issues/19104 18
19. 😈 小惡魔的啓示：Regex Backtracking /^😈*升?😈*$/.match?("😈😈😈已讀") 因為想讓大家方便自己玩玩看，這邊用 regex101 現有的引擎呈現回溯，如果想觀察 Ruby 的 Onigmo 引擎行為，可以編譯時開 啟 DEBUG 設定，並印出 trace 賞玩！ 19
20. 🍿 #19104 Regexp#match Optimization - 發布功能 Ruby 3.2.0 Released (25 Dec 2022) 20
21. 🍿 #19104 Regexp#match Optimization - 有趣的討論 Matz 第一個按了喜歡 (? 他唯一擔心是記憶體用量。 也不容易繼續瞎猜更多假設 性 case，決定發布 preview 來 得到更多實測。 https://bugs.ruby-lang.org/issues/19104 回想起 Symbol 沒 GC 時代的 DoS 陰影... 21
22. 🍿 #19104 Regexp#match Optimization - 有趣的討論 • 是以 位元陣列(bit-array) 記憶，1 bit 存 1 狀態，8 個狀態才占用 1 byte。 • 即使 字串很長，分支指令數量 通常不多 (上限約 80)，相乘可接受。 • 回溯（Backtracks）次數超過特定閾值時，才會啟動此機制去花記憶體。 22
23. 🍿 #19104 Regexp#match Optimization - 有趣的討論 今天先看一眼就好！Ruby 3.2 效能改善不支援： 1. 2. 3. 複雜語法（如 Back-reference \1） 破壞了快取運作的數學基礎 特殊巢狀結構（如 (a{2,3})*） 邏輯過於複雜，難以確保正確性 超大數值範圍（如 (a|b){100000,200000}） 會導致記憶體開銷過大 23
24. 🍿 #19104 Regexp#match Optimization - 有趣的討論 Mame 和 Eregon 針對「如何 讓用戶得知某 regex 可不可 最佳化」 • Warning？ Error？ 是否搭配 opt-in flag？ • 確認用的 API？ https://bugs.ruby-lang.org/issues/19104 → 教育與提醒義務 vs. 使用者體驗與相容性 24
25. 🍿 #19104 Regexp#match Optimization - 有趣的討論 最後決定是，提供 user 確認用的 API （後面我會介紹） Mame 也正式提名 make_now_just 為 committer 👏 https://bugs.ruby-lang.org/issues/19194 25
26. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ 26
27. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ Regexp#linear_time? 27
28. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ Regexp#linear_time? 28
29. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ Regexp#linear_time? …想到 Linter 就 想到 RuboCop！ …扎實的許願 ?! 29
30. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ Regexp#linear_time? … 想到 Linter 就想到 RuboCop? 哈哈，我在 RubyKaigi 後也馬上做了 PoC！這 是我的 KaigiEffect！ 我想，被標示出來後， fix 不太容易實做，可 能也不是每個用 戶都有能力馬上去改進這 些 Regex 🤔 另外，你點出 引擎依賴特定 Ruby 版本 確實 是個問題。例如用 Ruby 3.3 跑 TargetRubyVersion: 3.2 的靜態分 析時 CI 和 Prod 預期的結果可能不一致。 或是，可能實作在 rubocop core 以外的第三 方 gem？ 30
31. 󰟲 我也想小心，但人腦轉不過來啦，有沒有好用工具？ makenowjust-labs.github.io/recheck/docs/usage/as-eslint-plugin/ 31
32. 🚨 還是有風險？！Rails 和 GitLab 的 CVE 案例 32
33. 🚨 GitLab CVE-2021-39933 33
34. 🚨 GitLab CVE-2021-39933 34
35. 🚨 GitLab CVE-2021-39933 coding: ;;; (很多換行) x 35
36. 🚨 GitLab CVE-2021-39933 v14.5.2 coding: ;;; (很多換行) x 36
37. 🚨 GitLab CVE-2021-39933 v14.5.2 coding: ;;; (很多換行) x 37
38. 🚨 GitLab CVE-2021-39933 v14.5.2 coding: ;;; (很多換行) x 38
39. 🚨 Rails CVE-2026-33169 39
40. 🚨 Rails CVE-2026-33169 40
41. 🚨 Rails CVE-2026-33169 41
42. 🚨 Rails CVE-2026-33169 v8.1.2.1 main branch 42
43. 🚨 Rails CVE-2026-33169 v8.1.2.1 main branch O(n) O(n) 43
44. 🚨 Rails CVE-2026-33169 v8.1.2.1 main branch O(n) 44
45. 🚨 還是有風險？！Rails 和 GitLab 的 CVE 案例 [ 輸入字串 ] • 記得限制長度（...產品需求允許的話） [ regex 本人 ] • 如有 自訂輸入 regex 需求...請警鈴大作 • 善用檢查工具 • 利用 Timeout • 把 效能-資安 的關聯性，當成一個規格，讓你的開發夥伴知道 • … 提升人類對語法的敏銳度？ regexcrossword.com [ 更全面的看待複雜度 ] • 可能 regex 貢獻一部分維度，跟其他 Ruby 或 Rails 實作方式打組合拳 45
46. 🚨 還是有風險？！Rails 和 GitLab 的 CVE 案例 [ 輸入字串 ] • 記得限制長度（...產品需求允許的話） [ regex 本人 ] • 如有 自訂輸入 regex 需求...請警鈴大作 • 善用檢查工具 • 利用 Timeout • 把 效能-資安 的關聯性，當成一個規格，讓你的開發夥伴知道 • … 提升人類對語法的敏銳度？ regexcrossword.com [ 更全面的看待複雜度 ] • 可能 regex 貢獻一部分維度，跟其他 Ruby 或 Rails 實作方式打組合拳 46
47. 🚨 還是有風險？！Rails 和 GitLab 的 CVE 案例 [ 輸入字串 ] • 記得限制長度（...產品需求允許的話） [ regex 本人 ] • 如有 自訂輸入 regex 需求...請警鈴大作 • 善用檢查工具 • 利用 Timeout • 把 效能-資安 的關聯性，當成一個規格，讓你的開發夥伴知道 • … 提升人類對語法的敏銳度？ regexcrossword.com 回家作業！ GitLab CVE-2026-1388 跟 Rails 路由有關， 我找到的相關 Patch 程式碼（不是修 regex） [ 更全面的看待複雜度 ] • 可能 regex 貢獻一部分維度，跟其他 Ruby 或 Rails 實作方式打組合拳 47
48. 👀 延伸小聊：Timing Attack？ 48
49. 👀 延伸小聊：Timing Attack？ 今年 3 月 RubyJam Meetup 的厲害聽眾提問，我也還在探索中，與眾分！ [ Timing Attack ] 一種 Side-Channel Attack。藉由系統性地變化輸入，重複測量系統處理這些輸入所花 費的時間，統計推斷出程式正常輸出本身不會透露的秘密資訊。 • 理論上，regex 的回溯，確實有「處理時間」隨著「輸入跟秘密的吻合程度」改變 • 實作上，我還沒想出一個漂亮的例子來警世 🙈 • 社群夥伴建議：如果真要做秘密比對，盡量用 secure_compare 做單純的字串比對 49
50. 󰝊 延伸小聊：來自 RubyKaigi 2026 的 第一手 Regexp 未來動向！ 50
51. 󰝊 來自 RubyKaigi 2026 的第一手 Regexp 未來動向！ (Re)make Regexp in Ruby: Democratizing internals for the JIT https://rubykaigi.org/2026/presentations/ma kenowjust.html 51
52. 󰝊 來自 RubyKaigi 2026 的第一手 Regexp 未來動向！ (Re)make Regexp in Ruby: Democratizing internals for the JIT → 揭露現有架構的混亂與 bug → 提出 專案 Naraku 及其目標 → 用實驗性的純 Ruby DFA 引擎 (!!!) 驗證 JIT 加速的 可能性 與 現有侷限 → 收斂到務實的漸進式重寫計畫 （C 為主、Ruby 逐步導入、IR 中介表示式） https://speakerdeck.com/makenowjust/re-make-regexp-in-ruby-democratizing-internals-for-the-jit https://rubykaigi.org/2026/presentations/ma kenowjust.html 52
53. 󰝊 來自 RubyKaigi 2026 的第一手 Regexp 未來動向！ (Re)make Regexp in Ruby: Democratizing internals for the JIT → 揭露現有架構的混亂與 bug → 提出 專案 Naraku 及其目標 → 用實驗性的純 Ruby DFA 引擎 (!!!) 驗證 JIT 加速的 可能性 與 現有侷限 → 收斂到務實的漸進式重寫計畫 （C 為主、Ruby 逐步導入、IR 中介表示式） https://rubykaigi.org/2026/presentations/ma kenowjust.html 53
54. 🤔 為什麼想在 2026 重提 ReDoS 議題 54
55. 🤔 為什麼想在 2026 重提 ReDoS 議題 「每次提起升版就被已讀。」 https://www.ruby-lang.org/en/downloads/branches/ 55
56. 🤔 為什麼想在 2026 重提 ReDoS 議題 「輸入 的 不確定性」 Huli (2025). 從冷知識到漏洞，你不懂的Web，駭客懂. WebConf Taiwan 2025. 56
57. 🤔 為什麼想在 2026 重提 ReDoS 議題 「 LLM 輸入的不確定性」 • 生成 字串內容 內容與長度的隨機性。 無論由使用者、系統內部生成， 生成又長又多變的內容，變得更容易了。 • 生成 好像正確的 Regex 作為功能本身， LLM 寫出的 Regex 雖能對應需求， 但可能沒考慮到效能最佳化。 作為功能的輸入，要更加小心... …無心的使用者 、有心的攻擊方。 57
58. 🤔 為什麼想在 2026 重提 ReDoS 議題 「 LLM 輸入的不確定性」 • 生成 字串內容 內容與長度的隨機性。 無論由使用者、系統內部生成， 生成又長又多變的內容，變得更容易了。 • 生成 好像正確的 Regex 作為功能本身， LLM 寫出的 Regex 雖能對應需求， 但可能沒考慮到效能最佳化。 作為功能的輸入，要更加小心... …無心的使用者 、有心的攻擊方。 58
59. 🤔 為什麼想在 2026 重提 ReDoS 議題 2023~2026 很棒的演講，留友看！ https://rubykaigi.org/2023/presentations/maken https://rubykaigi.org/2023/presentations/lmt_swall owjust.html ow.html https://rubykaigi.org/2026/presentations/ma kenowjust.html https://webconf.tw/agenda/17 59
60. 🤔 為什麼想在 2026 重提 ReDoS 議題 最後，用 RubyKaigi 2023 講者的勵志結尾與 大家共勉 💪 今天聊了好多人的參與和考量： • Ruby 核心團隊 • 週邊套件貢獻者的反應(Rails, Rubocop) • 研討會講者的關注 • CVE 提出者 / 修復者 雖然還是怕得要死 🥬 🐣 https://youtu.be/CEvSx1D3dFQ 我覺得整個社群正陪我一起努力！ 60
61. > slides.last == 'Thank You!' => true Speaker.find_by(name: 'Kasa') Date.new(2026, 8, 9) 61
62. 聽說...你想 參與技術社群？ linktr.ee/rubytaiwan2008 Booth @ TR-309 !!! 62