GitLab đã cập nhật, lỗ hổng vẫn còn
Alpine Linux đã cập nhật lên GitLab 19.3.6, nhưng lỗ hổng CVE-2026-97229 vẫn chưa được vá trong môi trường của họ. Nguyên nhân nằm ở một lớp bên dưới: ảnh container của Alpine Linux sử dụng Ruby tiêu chuẩn, trong khi lỗ hổng nằm trong Ruby. Số phiên bản GitLab vì thế chưa đủ để kết luận hệ thống đã an toàn trước lỗi này.
Theo TMGS, đây là chi tiết đáng quan tâm nhất của vụ việc. Một báo cáo vận hành ghi “đã nâng cấp” có thể đúng về thao tác, nhưng vẫn thiếu bằng chứng rằng thành phần chứa lỗ hổng đã được thay thế hoặc sửa chữa. Với người chịu trách nhiệm phê duyệt đóng một cảnh báo bảo mật, hai việc đó cần được kiểm tra riêng.
Đường đi từ cấu hình CI/CD xuống Ruby
CVE-2026-97229 có điểm CVSS 10/10, bắt nguồn từ việc xác thực biểu thức chính quy không đầy đủ trong Onigmo, bộ máy biểu thức chính quy của Ruby. GitLab cho biết lỗi có thể cho phép người dùng chưa xác thực thực thi mã tùy ý trên máy chủ thông qua biểu thức chính quy được tạo đặc biệt trong cấu hình CI/CD.
Trong ngày 20 và 21 tháng 10, một tác nhân đe dọa đã nhắm vào máy chủ GitLab của Alpine Linux bằng cách khai thác lỗ hổng này. Theo mô tả của Alpine Linux, kẻ tấn công dùng tài khoản mới đăng ký để gửi cấu hình CI được tạo riêng, khiến tiến trình worker bị sập. Đây là hành vi được ghi nhận trong vụ việc; khả năng thực thi mã trên máy chủ cần được đánh giá riêng.
Vì sao vẫn dựng lại máy chủ?
Nguồn tin mô tả cuộc tấn công là thất bại. Tuy nhiên, Alpine Linux đưa ra một giới hạn quan trọng: họ chưa tìm thấy bằng chứng kẻ tấn công chạy mã trên máy chủ, nhưng không thể loại trừ khả năng đó. Cần giữ nguyên cả hai vế khi đánh giá sự cố, thay vì biến “chưa thấy bằng chứng” thành kết luận chắc chắn rằng không có thực thi mã.
Alpine Linux đã dựng lại máy chủ từ đầu. Tổ chức cũng cho biết các kiểm tra cho thấy kho aports, các gói và những bản phát hành ngày 21 tháng 10 không bị can thiệp. Kết quả kiểm tra tính toàn vẹn này có ý nghĩa cụ thể đối với các tài sản được nêu; nó không xóa đi giới hạn điều tra mà Alpine Linux đã công bố.
Theo nhận định của TMGS, quyết định dựng lại máy chủ cho thấy cách xử lý thận trọng khi bằng chứng chưa đủ để khép lại mọi khả năng. Với doanh nghiệp, giá trị của điều tra không chỉ nằm ở một nhãn “thành công” hay “thất bại”, mà còn ở việc xác định điều gì đã được kiểm chứng và điều gì còn chưa rõ.
Điều kiện để đóng một phiếu vá lỗi
TMGS khuyến nghị doanh nghiệp Việt Nam đang tự vận hành GitLab bổ sung bước xác minh thành phần phụ thuộc vào quy trình vá. Nếu đội phát triển quản lý GitLab còn đội hạ tầng quản lý ảnh container và Ruby, phiếu xử lý cần chỉ rõ ai chịu trách nhiệm xác nhận từng lớp. Việc bàn giao giữa các đội không nên chỉ dừng ở thông báo nâng cấp thành công.
- Xác định thành phần thực sự đang chạy: kiểm kê phiên bản GitLab, Ruby và nguồn gốc ảnh container trong môi trường triển khai.
- Đối chiếu hướng dẫn khắc phục: xác nhận biện pháp áp dụng có xử lý thành phần chứa lỗ hổng, đồng thời kiểm tra môi trường đang chạy sau cập nhật.
- Giữ bằng chứng khi có dấu hiệu bất thường: bảo toàn nhật ký liên quan đến tài khoản mới, thay đổi cấu hình CI và lỗi worker để phục vụ điều tra.
- Kiểm tra tài sản đầu ra: khi nghi ngờ máy chủ bị tác động, rà soát tính toàn vẹn của mã nguồn và các gói phát hành có liên quan.
Đối với CISO, câu hỏi nghiệm thu hữu ích là: “Bằng chứng nào cho thấy thành phần có lỗi đã được xử lý trong hệ thống đang chạy?” Trường hợp Alpine Linux cho thấy vì sao chỉ một dòng phiên bản ứng dụng chưa trả lời đủ câu hỏi đó.
Nguồn tham khảo
SecurityWeek: Max-Severity GitLab Vulnerability Exploited Against Alpine Linux