Ngày 23/10/2026, dự án Ruby phát hành ba bản Ruby 4.0.9, 3.4.12 và 3.3.13 để sửa lỗi trong Onigmo, bộ máy biểu thức chính quy (regex) của Ruby. Theo thông báo trên ruby-lang.org, GitLab phát hiện các pattern được dựng đặc biệt có thể làm hỏng bộ nhớ ngay lúc biên dịch regex. Từ đó có thể dẫn tới thực thi mã từ xa trên máy chủ GitLab. Đây là gốc của bốn CVE GitLab, trong đó có CVE-2026-110264 điểm CVSS 10 mà GitLab vá ở bản 19.5.1.
Tóm tắt nhanh
- Bản vá: Ruby 4.0.9, 3.4.12, 3.3.13 (23/10/2026).
- Lỗi: ba lỗi hỏng bộ nhớ trong Onigmo khi biên dịch regex: double free, tràn số nguyên khi tính kích thước pattern, tràn ID nội bộ khi pattern có nhiều lượng từ lặp.
- Ai bị ảnh hưởng: ứng dụng biên dịch regex từ chuỗi người dùng nhập.
- Không có tác dụng:
Regexp.timeoutvà giới hạn độ dài pattern. - Mã theo dõi: dùng CVE của GitLab, Ruby chưa xin CVE riêng.
Ba lỗi Onigmo và các CVE GitLab tương ứng
Bảng dưới tổng hợp từ thông báo của Ruby:
| CVE GitLab | Lỗi trong Ruby | Bản Ruby đầu tiên có bản sửa |
|---|---|---|
| CVE-2026-89078 | Double free khi phân tích pattern thất bại sau toán tử lựa chọn (alternation) | 4.0.0, 3.4.12, 3.3.13 |
| CVE-2026-93577, CVE-2026-97229 | Tràn số nguyên khi tính kích thước pattern đã biên dịch | 4.0.8, 3.4.12, 3.3.13 |
| CVE-2026-110264 | Tràn ID nội bộ khi pattern có rất nhiều lượng từ lặp | 4.0.9, 3.4.12, 3.3.13 |
Phía GitLab, các lỗi này được vá lần lượt ở GitLab 19.4.1, 19.4.2 và 19.5.1. Theo Ruby, Johan Carlsson (joaxcar) là người phát hiện lỗi tràn số nguyên qua chương trình bug bounty của GitLab. GitLab sau đó báo cáo và phối hợp sửa lỗi với Ruby.
Đáng chú ý, nhánh Ruby 3.3 vốn chỉ còn ở chế độ bảo trì bảo mật. Bản 3.3.13 được phát hành như một ngoại lệ vì GitLab đã gán CVE cho các lỗi này.
Ứng dụng nào thực sự gặp rủi ro?
Theo Ruby, chỉ ứng dụng biên dịch regex từ chuỗi kẻ tấn công kiểm soát được mới bị ảnh hưởng. Các dạng thường gặp:
Regexp.new(params[:q])
Regexp.union(user_list)
Regexp.compile(input)
/#{input}/
Tình huống thực tế hay gặp là ô tìm kiếm cho nhập regex, bộ lọc log, quy tắc định tuyến hoặc cấu hình do người dùng tự khai báo. Ứng dụng chỉ dùng regex viết sẵn trong mã nguồn thì không bị ảnh hưởng.
Ruby cũng nhấn mạnh hai điều. Regexp.timeout không bảo vệ trước các lỗi này. Giới hạn độ dài pattern cũng không đáng tin, vì một số lỗi kích hoạt được bằng pattern ngắn.
Cách kiểm tra và nâng cấp Ruby trên VPS
Kiểm tra phiên bản
# Ruby mặc định trong PATH
ruby -v
# Nếu dùng rbenv hoặc rvm
rbenv versions
rvm list
# Tìm mã biên dịch regex từ biến trong dự án
grep -rnE "Regexp\.(new|union|compile)" app/ lib/
Lệnh grep chỉ giúp khoanh vùng. Bạn cần xem chuỗi truyền vào có đến từ người dùng hay không, và tìm thêm các literal có chèn biến dạng /#{...}/.
Nâng cấp
# rbenv (cập nhật ruby-build trước)
git -C "$(rbenv root)"/plugins/ruby-build pull
rbenv install 3.4.12
rbenv global 3.4.12
# rvm
rvm get stable
rvm install 3.4.12
Sau khi nâng cấp, chạy lại bundle install, kiểm tra ứng dụng rồi khởi động lại Puma, Unicorn, Sidekiq hoặc dịch vụ systemd liên quan. Nếu dùng Ruby từ gói của bản phân phối (apt, dnf), hãy theo dõi bản cập nhật bảo mật của bản phân phối. Các bản này thường được backport và giữ nguyên số phiên bản.
Với Docker
Đổi base image sang tag Ruby mới, ví dụ ruby:3.4.12, rồi build lại với docker build --pull.
Nếu chưa thể nâng cấp
- Theo Ruby: tránh biên dịch regex từ dữ liệu không tin cậy.
- Nếu cần tìm kiếm theo chuỗi người dùng nhập, dùng
Regexp.escape(input)để biến chuỗi thành literal, hoặc dùng so khớp chuỗi thông thường nhưinclude?,start_with?. - Với GitLab tự cài, nâng lên bản vá mới nhất theo khuyến cáo của GitLab. Gói Omnibus đi kèm Ruby riêng, không nên tự thay.
Có cần lo về CVE cho Ruby?
Ruby cho biết "ít nhất là tạm thời" chưa xin mã CVE cho các bản sửa này. Dự án sẽ thảo luận về tài liệu hướng dẫn dùng pattern không tin cậy, về việc có coi đây là lỗ hổng hay không, và có xin CVE hay không. Trong lúc chờ, hãy dùng các mã CVE của GitLab khi theo dõi trong hệ thống quản lý lỗ hổng.