GitLab vá lỗ hổng thực thi mã từ xa nghiêm trọng ảnh hưởng đến mọi phiên bản kể từ năm 2014

GitLab đã phát hành các bản cập nhật bảo mật khẩn cấp vào ngày 21 tháng 10 để giải quyết một lỗ hổng nghiêm trọng cho phép kẻ tấn công thực thi mã tùy ý trên các máy chủ tự quản lý mà không cần xác thực. Lỗ hổng này, được định danh là CVE-2026-110264, đạt điểm tuyệt đối 10.0 theo Hệ thống Đánh giá Điểm Lỗ hổng Chung (CVSS) và ảnh hưởng đến mọi bản phát hành của phần mềm kể từ phiên bản 7.0, ra mắt vào năm 2014.

Bản vá này mang tính cấp bách ngay cả với những quản trị viên đã áp dụng bản cập nhật bảo mật trước đó vào ngày 12 tháng 10. Bản sửa lỗi cũ chỉ bao phủ các phiên bản 19.2 trở lên, khiến các cài đặt cũ hơn vẫn bị lộ, trong khi các phiên bản đã được sửa mới nằm ở mức bản vá cao hơn một bậc so với các bản phát hành gần đây. Do đó, nhiều hệ thống được cho là an toàn vẫn dễ bị tổn thương cho đến khi vòng cập nhật mới nhất này được áp dụng.

Chuyện gì đã xảy ra

Lỗ hổng bắt nguồn từ một sự tràn số nguyên (integer overflow) trong Onigmo, công cụ biểu thức chính quy (regular expression engine) tích hợp sẵn trong Ruby mà GitLab đóng gói và vá trong các bản phân phối riêng của mình. Khi trình biên dịch xử lý một biểu thức chính quy được tạo ra đặc biệt, nó có thể kích hoạt sự tràn này, tiềm ẩn nguy cơ cho phép người dùng chưa xác thực chạy mã trên máy chủ host. GitLab chưa tiết lộ các điều kiện cụ thể cần thiết để khai thác lỗ hổng, nghĩa là các quản trị viên không thể dựa vào việc thay đổi cấu hình để giảm thiểu rủi ro.

GitLab đã giải quyết vấn đề bằng cách phát hành các phiên bản đã sửa lỗi đồng thời trên bảy nhánh phát hành khác nhau. Phạm vi rộng lớn này bao gồm bốn phiên bản cũ hơn chính sách hỗ trợ tiêu chuẩn của GitLab, vốn thường chỉ bao gồm bản phát hành hiện tại và hai phiên bản hàng tháng trước đó. Công ty tuyên bố họ dành nỗ lực backporting ngoại lệ này cho các vấn đề nghiêm trọng, thừa nhận tính chất phổ biến của điểm yếu cốt lõi trong công cụ nền tảng.

Mặc dù GitLab báo cáo không có bằng chứng nào cho thấy lỗ hổng cụ thể này đã bị khai thác trong thực tế, và nó cũng chưa xuất hiện trong danh mục các lỗ hổng bị khai thác đã biết của CISA Hoa Kỳ, hồ sơ rủi ro vẫn cực kỳ cao. Cùng một nhà nghiên cứu, được biết đến với tên gọi joaxcar, đã báo cáo ba lỗ hổng thực thi mã khác trong cùng công cụ regex này trong tháng qua. Khác với các vấn đề trước đó, vốn chỉ giới hạn ở các phiên bản mới hơn hoặc yêu cầu quyền truy cập đã xác thực, lỗ hổng này vươn tới hơn một thập kỷ lịch sử phần mềm và không yêu cầu đăng nhập.

Chi tiết quan trọng

• ID lỗ hổng: CVE-2026-110264, được đánh giá 10.0 (Critical/Nghiêm trọng) trên thang đo CVSS.
• Phiên bản bị ảnh hưởng: Tất cả các instance GitLab tự quản lý từ phiên bản 7.0 (2014) đến các bản phát hành trước khi vá mới nhất.
• Nguyên nhân gốc rễ: Tràn số nguyên trong trình biên dịch biểu thức chính quy Onigmo khi xử lý các biểu thức được tạo ra đặc biệt.
• Vector tấn công: Thực thi mã từ xa không cần xác thực; không cần đăng nhập hay tương tác của người dùng.
• Khả năng khắc phục: Các bản vá đã được phát hành cho các phiên bản 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 và 18.11.13.
• Phát hiện: GitLab cung cấp hai quy tắc phát hiện định dạng Sigma, "Onigmo native worker crash" và "Org mode render error burst", để giám sát nhật ký ứng dụng.

Bối cảnh

Biểu thức chính quy là các mẫu được sử dụng để khớp các tổ hợp ký tự trong chuỗi, được dùng rộng rãi trong lập trình cho chức năng xác thực dữ liệu và tìm kiếm. Công cụ xử lý các mẫu này, trong trường hợp này là Onigmo, phải xử lý các đầu vào phức tạp một cách hiệu quả. Sự tràn số nguyên xảy ra khi một phép tính tạo ra con số lớn hơn không gian lưu trữ được cấp phát cho nó, khiến giá trị bị cuộn lại thành một số âm hoặc một số dương nhỏ. Trong bối cảnh bảo mật, điều này có thể làm hỏng các cấu trúc bộ nhớ, cho phép kẻ tấn công chèn và thực thi mã độc hại.

GitLab đóng gói phiên bản riêng của trình thông dịch Ruby và các thư viện liên quan, bao gồm cả Onigmo. Vì công cụ này được nhúng trong mọi phiên bản GitLab kể từ 7.0, lỗ hổng tồn tại khắp nơi trên toàn bộ cơ sở cài đặt của các instance tự quản lý. Người dùng trên đám mây tại GitLab.com không bị ảnh hưởng vì nhà cung cấp quản lý hạ tầng nền tảng và đã triển khai bản sửa lỗi.

Tại sao điều này quan trọng

Đối với các nhóm vận hành instance GitLab tự lưu trữ, sự cố này làm nổi bật những rủi ro ẩn giấu của các phụ thuộc phần mềm dài hạn. Ngay cả khi một tổ chức duy trì lịch trình vá lỗi nghiêm ngặt cho các phiên bản mới, độ sâu của lỗ hổng này có nghĩa là các instance di sản (legacy) hoặc những instance đang trong chu kỳ hỗ trợ mở rộng đều bị phơi bày nghiêm trọng. Việc bản vá ngày 12 tháng 10 không bao phủ các phiên bản cũ hơn tạo ra một khoảng trống nguy hiểm, nơi các quản trị viên có thể tin rằng họ được bảo vệ nhưng thực tế thì không.

Tác động vận hành của việc áp dụng bản sửa lỗi này không hề nhỏ. Các nâng cấp lên phiên bản 19.4.3 và 19.3.6 bao gồm các thay đổi schema cơ sở dữ liệu đòi hỏi thời gian ngừng hoạt động (downtime) trên các máy chủ đơn node. Đối với môi trường có tính sẵn sàng cao, điều này đòi hỏi kế hoạch cẩn thận sử dụng các quy trình nâng cấp không gián đoạn (zero-downtime upgrade) của GitLab cho các thiết lập multi-node. Các nhóm phải cân bằng giữa mối đe dọa bảo mật tức thời và sự gián đoạn dịch vụ tiềm ẩn do quá trình vá lỗi gây ra.

Hơn nữa, việc thiếu phương án tạm thời (workaround) có nghĩa là không có biện pháp ngăn chặn tức thời. Các quản trị viên không thể đơn giản tắt một tính năng hoặc điều chỉnh một cài đặt để chặn vector tấn công. Biện pháp bảo vệ dứt khoát duy nhất là nâng cấp lên một trong các phiên bản đã được vá. Điều này tạo áp lực lên các nhóm DevOps phải ưu tiên nhiệm vụ bảo trì này hơn các hạng mục lộ trình khác, có khả năng làm chậm trễ việc phát triển tính năng hoặc các cải tiến hạ tầng khác.

Bạn có thể làm gì

• Xác định phiên bản GitLab hiện tại của bạn và đối chiếu với bảng phiên bản đã sửa để xác định lộ trình nâng cấp cần thiết.
• Lên lịch một cửa sổ bảo trì ngay lập tức cho các instance đơn node, tính đến khả năng downtime do di chuyển cơ sở dữ liệu.
• Triển khai các quy tắc phát hiện Sigma được cung cấp vào hệ thống quản lý nhật ký của bạn để giám sát các sự kiện "Onigmo native worker crash" hoặc "Org mode render error burst".
• Xác minh rằng các cụm multi-node được cấu hình cho nâng cấp không gián đoạn trước khi khởi động quy trình vá để tránh gián đoạn dịch vụ.
• Xem xét nhật ký truy cập để tìm các hoạt động bất thường trước khi vá, mặc dù lưu ý rằng việc khai thác có thể để lại rất ít dấu vết nếu không có các quy tắc phát hiện cụ thể.
• Truyền đạt tính cấp bách đến các bên liên quan, nhấn mạnh rằng bản sửa lỗi này giải quyết một lỗ hổng tồn tại trong tất cả các phiên bản kể từ năm 2014, chứ không chỉ các bản phát hành gần đây.