Kẻ tấn công khai thác lỗ hổng GitLab trên Alpine Linux (CVSS 10.0)
"An attacker attempted to exploit a critical GitLab vulnerability (CVE-2026-97229, CVSS 10.0) on Alpine Linux's GitLab server. The vulnerability allows remote code execution via crafted regular expressions in CI configurations. Alpine Linux rebuilt the server, reset passwords, and updated Ruby to mitigate the risk, despite initially applying a GitLab update that was insufficient."
Lỗ hổng CVE-2026-97229 cho phép thực thi mã từ xa trên máy chủ GitLab, gây ra rủi ro bảo mật nghiêm trọng. Việc không cập nhật Ruby có thể khiến hệ thống dễ bị tấn công.
Sự cố này có thể gây gián đoạn dịch vụ, mất dữ liệu và tổn hại uy tín cho các tổ chức sử dụng GitLab. Việc khắc phục lỗ hổng đòi hỏi thời gian và nguồn lực, ảnh hưởng đến năng suất và chi phí.
Ngày 28 tháng 10, Alpine Linux cho biết một kẻ tấn công đã cố gắng khai thác lỗ hổng nghiêm trọng GitLab (CVE-2026-97229, CVSS 10.0) trên máy chủ GitLab của họ, một tuần sau khi GitLab phát hành bản vá.
Lỗ hổng này cho phép kẻ tấn công thực thi mã trên máy chủ GitLab thông qua biểu thức chính quy (regular expression) được tạo thủ công trong cấu hình CI. Alpine không tìm thấy bằng chứng về việc tấn công thành công, nhưng không thể loại trừ khả năng này, nên họ đã xây dựng lại máy chủ từ đầu và đặt lại mật khẩu cho tất cả tài khoản.
Bản vá của GitLab là một tập hợp các bản vá cho Ruby mà GitLab đóng gói trong các gói và hình ảnh container của mình. Tuy nhiên, máy chủ GitLab của Alpine sử dụng Ruby tiêu chuẩn, nên việc nâng cấp lên GitLab 19.3.6 vào ngày 22 tháng 10 không khắc phục được lỗ hổng. Alpine nhấn mạnh rằng, đối với những ai tự chạy GitLab trên Ruby do mình biên dịch hoặc trong container riêng, “chỉ nâng cấp GitLab là chưa đủ”. Các máy chủ này cũng cần Ruby 3.3.13, 3.4.12 hoặc 4.0.9 trở lên. Người dùng hình ảnh alpinelinux/gitlab của Alpine cần kéo lại phiên bản 19.3.6.
Máy chủ gitlab.alpinelinux.org lưu trữ aports, kho lưu trữ từ đó các gói của Alpine được xây dựng. Các gói được xây dựng từ ngày 20 đến 24 tháng 10, và bản phát hành ngày 21 tháng 10, đến từ các thay đổi aports được xác minh bằng các bản ghi bên ngoài GitLab. Alpine cũng đang mở rộng kiểm tra đến ngày 27 tháng 10, thời điểm họ đóng máy chủ. Các khóa ký các gói và bản phát hành của họ chưa bao giờ nằm trên máy chủ GitLab.
Cách thức tấn công diễn ra:
Vào ngày 13 tháng 10, Alpine đã nâng cấp máy chủ lên GitLab 19.3.4 thay vì 19.3.5, điều mà họ gọi là một sai lầm. Máy chủ vẫn ở phiên bản đó, không có bản vá ngày 12 tháng 10, khi một tài khoản mới đăng ký bắt đầu thăm dò nó vào ngày 20 tháng 10. Tài khoản này gửi các cấu hình CI được tạo thủ công đến máy chủ vào ngày 20 và 21 tháng 10. Chúng làm sập 8 tiến trình worker của GitLab và cuộc tấn công chính vào ngày 21 tháng 10 cũng gây ra lỗi 502 và khiến các công việc CI bị lỗi. Trong 4 lần sập, kẻ tấn công đã đi được một phần trong quá trình khai thác và thất bại ở bước tiếp theo. Kẻ tấn công cũng tải xuống hình ảnh container GitLab của Alpine, cho thấy họ đang điều chỉnh khai thác cho bản dựng chính xác của Alpine. Alpine đã chặn tài khoản này vào ngày 23 tháng 10. Kẻ tấn công quay lại vào ngày 25 và 26 tháng 10 và cố gắng quay lại, nhưng những nỗ lực này thất bại. Vào ngày 26 tháng 10, Alpine phát hiện ra rằng máy chủ vẫn dễ bị tấn công sau khi nâng cấp lên 19.3.6 vào ngày 22 tháng 10. Ngày hôm sau, họ đóng GitLab cho tất cả mọi người ngoại trừ các nhà phát triển và máy chủ xây dựng của mình và bắt đầu xây dựng lại nó. Quá trình xây dựng lại hoàn thành vào ngày 28 tháng 10. Alpine cũng đã thay thế các khóa bí mật của GitLab và máy chủ được xây dựng lại chạy Ruby 3.3.13 trở lên, có bản vá. Alpine đang thử nghiệm nó trước khi mở lại cho công chúng.
Alpine không tìm thấy dấu hiệu nào cho thấy mã của kẻ tấn công đã chạy trên máy chủ. Các phép đo thời gian thăm dò không cho thấy độ trễ nào; không có tệp, khóa, hook hoặc quy trình bất thường; và không có dữ liệu riêng tư nào được gửi trở lại kẻ tấn công thông qua bất kỳ yêu cầu web hoặc API nào mà Alpine có thể thấy. Tuy nhiên, họ không thể chắc chắn. “Một cuộc khai thác thành công sẽ không để lại dấu vết sập và không có dấu vết trong nhật ký web”, Alpine cho biết. Một số nhật ký từ ngày tấn công đã biến mất, bao gồm nhật ký công việc nền và hệ thống tệp của container cũ, và cả Alpine và nhà cung cấp dịch vụ lưu trữ của họ đều không ghi lại các kết nối mạng đi. Vì bằng chứng cần thiết để xác nhận việc thực thi mã không còn tồn tại, Alpine đã coi máy chủ là bị xâm phạm và xây dựng lại nó để loại bỏ bất kỳ điểm tựa nào mà một cuộc khai thác thành công có thể đã để lại.
Nếu cuộc tấn công thành công, những thông tin sau có thể bị lộ:
Địa chỉ email, tên và địa chỉ IP của tất cả người dùng Băm mật khẩu * Bí mật 2FA, biến CI/CD và token trình chạy * Thông tin xác thực webhook, tích hợp và gương đẩy * Token truy cập cá nhân, được lưu trữ dưới dạng băm * Kho lưu trữ riêng tư và các vấn đề và yêu cầu hợp nhất bí mật
Ngoài việc đặt lại mật khẩu và các khóa bí mật mới, Alpine chưa cho biết liệu token trình chạy, biến CI/CD, token truy cập hay thông tin xác thực tích hợp được lưu trữ trên máy chủ có được thay thế hay không.
Câu hỏi thường gặp
CVE-2026-97229 là gì?
CVE-2026-97229 là một lỗ hổng thực thi mã từ xa trong GitLab, cho phép kẻ tấn công chạy mã trên máy chủ GitLab thông qua biểu thức chính quy được tạo thủ công trong cấu hình CI.
Alpine Linux đã làm gì để khắc phục lỗ hổng?
Alpine Linux đã xây dựng lại máy chủ GitLab của họ từ đầu, đặt lại mật khẩu cho tất cả tài khoản và cập nhật Ruby lên phiên bản được vá (3.3.13 trở lên). Họ cũng đã thay thế các khóa bí mật của GitLab.
Tại sao việc nâng cấp GitLab không đủ để khắc phục lỗ hổng?
Việc nâng cấp GitLab chỉ vá Ruby trong các gói và hình ảnh container do GitLab cung cấp. Nếu máy chủ sử dụng Ruby được cài đặt riêng, cần phải cập nhật Ruby lên phiên bản được vá.
Những dữ liệu nào có thể bị lộ nếu cuộc tấn công thành công?
Nếu cuộc tấn công thành công, kẻ tấn công có thể truy cập địa chỉ email, tên, địa chỉ IP của người dùng, băm mật khẩu, bí mật 2FA, biến CI/CD, thông tin xác thực webhook, token truy cập cá nhân và kho lưu trữ riêng tư.
Góc nhìn của Orange Cloud
Theo chúng tôi, sự cố này nhấn mạnh tầm quan trọng của việc cập nhật không chỉ phần mềm GitLab mà còn cả các thành phần cơ bản như Ruby. Các doanh nghiệp Việt Nam sử dụng GitLab trên cơ sở hạ tầng tự quản lý nên kiểm tra phiên bản Ruby đang sử dụng và đảm bảo nó được cập nhật lên phiên bản được vá. Điều đáng chú ý là, việc chỉ cập nhật GitLab có thể không đủ nếu Ruby chưa được vá. Các tổ chức nên xem xét việc sử dụng hình ảnh container chính thức của GitLab, vì chúng thường bao gồm các bản vá Ruby mới nhất.