GitLab四宗RCE漏洞牽出Ruby Regexp引擎缺陷
GitLab近期處理的四宗遠端程式碼執行（RCE）漏洞，根源指向Ruby正規表示式引擎Onigmo的記憶體處理問題。iThome報道指出，GitLab已修補產品內所用的Ruby，而Ruby官方其後推出4.0.9、3.4.12及3.3.13，為底層問題提供修正。
對自託管GitLab管理員而言，首要工作是核對所部署GitLab版本的安全更新狀態，並依官方公告更新至已修補版本。報道提及，GitLab自9月23日起陸續修補四項相關漏洞；其中於10月21日修補的CVE-2026-110264，CVSS評分為10分，在特定條件下可讓未登入攻擊者執行任意程式碼。
關鍵在於誰能控制RegExp內容
這批問題並不代表所有Ruby程式都會受影響。iThome指出，觸發條件是應用程式把攻擊者可控制的字串當作正規表示式編譯，例如透過Regexp.new、Regexp.union或Regexp.compile，又或把外部輸入直接拼入正規表示式。相反，若程式只編譯由開發者預先撰寫的固定模式，則不屬於報道所述的受影響情境。
Onigmo在編譯特製模式時，可能出現重複釋放記憶體、結果大小計算錯誤，或因大量重複規則引致內部編號溢位；這些狀況可造成記憶體損壞。GitLab某些功能會把使用者提供的正規表示式交由Ruby編譯，因而成為攻擊面。
DevOps與開發團隊應怎樣處理
除更新GitLab外，維護Ruby服務的團隊應盤點所有可由外部人士提交、儲存或修改的搜尋規則、篩選器及模式設定，確認它們會否最終進入RegExp編譯流程。若不能即時升級，Ruby官方的建議是避免編譯不可信任輸入，而非依賴表面限制。
尤其要留意，Regexp.timeout只處理執行時間問題，不能防止這次涉及編譯階段記憶體錯誤；單靠限制輸入長度亦不可靠，因為部分問題可由短字串觸發。對提供自訂規則功能的內部工具而言，這意味著權限控制、輸入設計與升級節奏都需要一併檢視。
報道指部分修正已納入Ruby 4.0.0及4.0.8，4.0.9補齊最後一項；3.4.12及3.3.13則包含全部相關修正。下一步值得持續關注的是，各團隊自行開發的Ruby服務是否存在「不可信任字串直接編譯為RegExp」的路徑，以及相關GitLab實例是否已完成安全更新。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — GitLab四項RCE漏洞源頭，指向Ruby正規表示式引擎缺陷 — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
