Lỗ hổng GitLab nghiêm trọng nhất bị khai thác nhắm vào Alpine Linux
Lỗ hổng thực thi mã từ xa CVE-2026-97229 trong GitLab với điểm CVSS 10/10 đã bị khai thác chỉ một tuần sau khi công bố, nhắm vào máy chủ GitLab của bản phân phối Alpine Linux. Cuộc tấn công thất bại nhưng Alpine Linux buộc phải dựng lại toàn bộ máy chủ từ đầu, đồng thời CISA đã đưa lỗ hổng vào danh mục KEV yêu cầu vá khẩn cấp.

GitLab vừa trải qua một trong những sự cố bảo mật nghiêm trọng nhất trong thời gian gần đây khi lỗ hổng thực thi mã từ xa mang mã CVE-2026-97229, với điểm CVSS tối đa 10/10, bị khai thác chỉ một tuần sau khi được công bố. Nạn nhân trong lần này là bản phân phối Alpine Linux.
Lỗ hổng nằm ở đâu?
Theo thông báo ngày 12/10 của GitLab, lỗ hổng bắt nguồn từ việc Onigmo — engine biểu thức chính quy (regex) của Ruby — kiểm tra dữ liệu đầu vào không đầy đủ. Điều này "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ủ GitLab thông qua một biểu thức chính quy được thiết kế đặc biệt trong cấu hình CI/CD".
Lỗ hổng nghiêm trọng trong GitLab bị khai thác
Điểm đáng lo ngại là kẻ tấn công không cần tài khoản hợp lệ hay quyền truy cập đặc biệt. Chỉ cần một cấu hình pipeline CI/CD chứa regex độc hại là đủ để kích hoạt lỗ hổng, biến đây thành dạng lỗ hổng cực kỳ nguy hiểm với các hệ thống GitLab công khai cho phép đăng ký tài khoản.
Alpine Linux bị nhắm mục tiêu
Theo Alpine Linux, kẻ tấn công đã nhắm vào máy chủ GitLab của tổ chức này trong hai ngày 20 và 21/10. Cuộc tấn công đã thất bại, nhưng ban quản lý dự án vẫn quyết định dựng lại máy chủ từ đầu để đảm bảo an toàn.
"Kiểm tra của chúng tôi cho thấy kho aports, các gói phần mềm và các bản phát hành ngày 21/10 đều không bị can thiệp trái phép", Alpine Linux khẳng định.
Dù vậy, đơn vị này vẫn đang kiểm thử lại máy chủ GitLab trước khi mở cửa công khai trở lại và đã đặt lại toàn bộ mật khẩu. Họ cũng cảnh báo về các nỗ lực đăng nhập tự động bằng mật khẩu bị rò rỉ từ những vụ vi phạm dữ liệu khác.
Kẻ tấn công đã làm gì?
Trong vụ tấn công, tin tặc sử dụng một tài khoản mới đăng ký để gửi các cấu hình CI độc hại tới máy chủ GitLab của Alpine Linux, khiến tiến trình worker bị sập. Theo mô tả của Alpine Linux:
- Trong 4 lần sập, kẻ tấn công đã tiến được một phần của quy trình khai thác nhưng thất bại ở bước tiếp theo.
- Kẻ tấn công còn tải xuống image container GitLab của Alpine, cho thấy chúng đang tinh chỉnh mã khai thác cho khớp chính xác với bản build của tổ chức.
- Chưa có bằng chứng cho thấy kẻ tấn công chạy được mã trên máy chủ, nhưng điều này cũng không thể loại trừ hoàn toàn.
Cạm bẫy khi vá lỗi
Điểm mấu chốt khiến sự cố này phức tạp: lỗ hổng gốc nằm ở Ruby chứ không phải GitLab. Do image của Alpine Linux chạy Ruby tiêu chuẩn, việc nâng cấp lên GitLab 19.3.6 không giải quyết được vấn đề.
"Nếu bạn chạy GitLab với Ruby riêng (từ mã nguồn hoặc image container tự xây dựng) thay vì dùng gói của GitLab, chỉ nâng cấp GitLab là chưa đủ: bạn còn cần Ruby 3.3.13, 3.4.12, 4.0.9 trở lên", Alpine Linux lưu ý.
Đây là bài học quan trọng cho các đội DevOps tại Việt Nam đang tự vận hành GitLab trên hạ tầng riêng hoặc dùng image tùy chỉnh. Việc kiểm tra phiên bản Ruby trong môi trường CI/CD cần được đưa vào quy trình vá lỗi định kỳ, thay vì chỉ chăm chăm cập nhật GitLab.
Cảnh báo bảo mật và các lỗ hổng khai thác
CISA vào cuộc
Hôm thứ Năm, Cơ quan An ninh mạng và Hạ tầng Mỹ (CISA) đã thêm CVE-2026-97229 vào danh mục Lỗ hổng đang bị khai thác (KEV). Theo chỉ thị BOD 26-04, các cơ quan liên bang Mỹ được yêu cầu vá lỗ hổng này trong vòng ba ngày.
Việc đưa vào KEV cho thấy mức độ nghiêm trọng và mức độ khai thác thực tế của lỗ hổng. Với các doanh nghiệp Việt Nam sử dụng GitLab — đặc biệt là các hệ thống có thể truy cập từ internet và cho phép đăng ký công khai — đây là lời cảnh báo cần xử lý ngay lập tức.
Khuyến nghị cho người dùng Việt Nam
- Nâng cấp GitLab lên phiên bản mới nhất nếu đang dùng gói chính thức của GitLab.
- Kiểm tra phiên bản Ruby trong môi trường tự vận hành và cập nhật lên 3.3.13, 3.4.12, 4.0.9 trở lên.
- Hạn chế đăng ký công khai trên các instance GitLab tiếp xúc internet, đồng thời bật xác thực hai lớp và giám sát đăng nhập bất thường.
- Rà soát log của worker CI để phát hiện sớm các pipeline bị sập hoặc cấu hình đáng ngờ.
Vụ việc một lần nữa cho thấy chuỗi cung ứng phần mềm và các thành phần phụ thuộc (như Ruby) có thể trở thành điểm yếu chí mạng, ngay cả khi bản thân ứng dụng chính đã được cập nhật.
