Alpine Linux bị tấn công qua lỗ hổng GitLab nghiêm trọng: vá GitLab thôi là chưa đủ

Alpine Linux vừa công bố một sự cố an ninh đáng chú ý: kẻ tấn công đã tìm cách khai thác lỗ hổng nghiêm trọng CVE-2026-97229 trên máy chủ GitLab nội bộ của dự án. Dù chưa tìm thấy bằng chứng cho thấy vụ tấn công thành công, đội ngũ vận hành vẫn quyết định xử lý theo hướng thận trọng nhất — coi hệ thống đã bị xâm nhập và dựng lại GitLab từ con số không.

Chuyện gì đã xảy ra?

Trong hai ngày 20 và 21/10, một tài khoản mới đăng ký đã gửi các cấu hình CI được thiết kế đặc biệt tới máy chủ GitLab của Alpine Linux, lúc đó vẫn chạy phiên bản 19.3.4 và chưa được vá bản cập nhật ngày 12/10.

Kết quả: các tiến trình worker của GitLab bị crash 8 lần. Đáng lo hơn, trong 4 lần crash đó, kẻ tấn công đã đi được một phần của chuỗi khai thác và chỉ thất bại ở bước tiếp theo. Kẻ tấn công còn tải về cả image container GitLab của Alpine — dấu hiệu 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 hệ thống.

Chúng tôi không tìm thấy bằng chứng nào cho thấy kẻ tấn công đã chạy được mã trên máy chủ, nhưng cũng không thể loại trừ khả năng đó.

Cái bẫy: nâng cấp GitLab không có nghĩa là đã vá

Đây là phần quan trọng nhất của sự cố và cũng là bài học cho mọi đội ngũ vận hành GitLab.

Lỗ hổng CVE-2026-97229 có điểm CVSS 10.0 — mức nghiêm trọng tối đa — nằm ở cách GitLab xử lý biểu thức chính quy (regex) trong cấu hình CI. Nhưng gốc rễ của vấn đề không phải mã của GitLab, mà là Onigmo, engine regex tích hợp trong Ruby.

Ngày 12/10, GitLab phát hành bản vá. Tuy nhiên bản vá đó thực chất là một tập patch áp lên Ruby mà GitLab đóng gói sẵn trong package và container image chính thức của mình. Mã nguồn Ruby gốc chỉ nhận được bản vá vào ngày 23/10, trong các phiên bản Ruby 3.3.13, 3.4.12 và 4.0.9.

Alpine Linux nâng cấp lên GitLab 19.3.6 vào ngày 22/10 — và lỗ hổng vẫn còn nguyên. Lý do: image của họ dùng Ruby tiêu chuẩn thay vì Ruby do GitLab đóng gói, nên không nhận được patch.

Nếu bạn tự vận hành GitLab với Ruby riêng (build từ source hoặc dùng container image tự tạo), chỉ nâng cấp GitLab là không đủ. Bạn cần Ruby 3.3.13, 3.4.12, 4.0.9 hoặc mới hơn.

Nếu bạn dùng image alpinelinux/gitlab, cần pull lại tag alpinelinux/gitlab:19.3.6. Chỉ image phát hành ngày 27/10 mới chứa Ruby 3.3.13 — mọi image 19.3.6 pull trước ngày đó, cùng toàn bộ các tag cũ hơn, đều dính lỗ hổng.

Ảnh hưởng lan rộng hơn GitLab

Vì lỗi nằm ở engine regex của Ruby, bất kỳ chương trình nào biên dịch regex từ dữ liệu đầu vào không đáng tin đều có nguy cơ. Đây không phải câu chuyện riêng của GitLab.

Các bản Alpine 3.22, 3.23, 3.24 và edge đã chuyển sang Ruby 3.4.12, còn Alpine 3.21 dùng Ruby 3.3.13 — tất cả đều đã có bản vá. Người dùng chỉ cần chạy apk upgrade.

Xử lý hậu quả: dựng lại từ đầu

Vì không thể loại trừ khả năng kẻ tấn công đã thực thi mã, và bằng chứng cần thiết để xác nhận điều đó đã không còn, Alpine chọn con đường khó hơn: xây dựng lại toàn bộ máy chủ GitLab từ đầu, xóa sạch mọi dấu vết mà một vụ khai thác thành công có thể để lại.

Toàn bộ mật khẩu đã được đặt lại. Khi GitLab hoạt động trở lại, người dùng cần đặt mật khẩu mới qua chức năng "Quên mật khẩu" trên trang đăng nhập.

Trong thời gian GitLab đóng cửa, các dịch vụ khác gồm mirror package, cgit và mailing list/IRC vẫn hoạt động bình thường.

Kiểm tra toàn diện: không phát hiện bị can thiệp

Đội ngũ Alpine đã đối chiếu chéo với các nguồn dữ liệu mà kẻ tấn công không thể chạm tới — bản clone của một lập trình viên và toàn bộ 45 máy build — và kết luận:

• Mọi commit trong aports từ ngày 20 đến 22/10 đều đến từ thao tác push có ghi nhận của lập trình viên đã biết
• Mọi package build từ 20 đến 24/10, trên mọi kiến trúc, đều khớp với commit công bố trên git.alpinelinux.org
• Các bản phát hành ngày 21/10 (3.21.9, 3.22.7, 3.23.7, 3.24.3) được build từ chính những commit đã xác minh đó

Do GitLab vẫn trong trạng thái dễ bị tổn thương cho đến khi bị đóng vào ngày 27/10, Alpine cho biết sẽ mở rộng phạm vi kiểm tra đến hết ngày này.

Bài học cho đội ngũ DevOps tại Việt Nam

Sự cố này là lời nhắc nhở rõ ràng cho các nhóm vận hành hạ tầng CI/CD:

• Kiểm tra kỹ thành phần phụ thuộc: một bản vá tưởng chừng đã xong ở tầng ứng dụng có thể vô hiệu nếu runtime bên dưới không được cập nhật. Đây là bài toán supply chain mà nhiều đội ngũ trong nước vẫn xem nhẹ.
• Đừng dùng chung mật khẩu cho tài khoản Git nội bộ: Alpine ghi nhận có các nỗ lực đăng nhập tự động nhắm vào GitLab của họ bằng mật khẩu rò rỉ từ các trang khác. Đây là kịch bản credential stuffing rất phổ biến.
• Cho phép người ngoài đăng ký tài khoản trên GitLab công khai cần cân nhắc kỹ — kẻ tấn công trong vụ này chỉ cần một tài khoản mới là đủ để gửi cấu hình CI độc hại.
• Khi không chắc chắn, hãy dựng lại: chi phí khôi phục hệ thống thường thấp hơn nhiều so với rủi ro để lại một backdoor không được phát hiện.

Mọi thắc mắc về sự cố có thể gửi về địa chỉ [email protected].