Alpine Linux xây dựng lại GitLab sau nỗ lực khai thác lỗ hổng regex nghiêm trọng trong Ruby

Vào ngày 20 và 21 tháng 10, một kẻ tấn công đã nhắm mục tiêu vào instance GitLab của Alpine Linux bằng cách khai thác một lỗ hổng nghiêm trọng trong engine biểu thức chính quy (regular expression) của Ruby. Mặc dù không có bằng chứng cho thấy việc thực thi mã độc đã thành công, đội ngũ kỹ thuật không thể loại trừ khả năng này nên đã quyết định xây dựng lại toàn bộ dịch vụ từ đầu để đảm bảo tính toàn vẹn.

Chuyện gì đã xảy ra

Sự cố xoay quanh CVE-2026-97229, một lỗ hổng nghiêm trọng với điểm CVSS là 10.0, ảnh hưởng đến cách GitLab đánh giá các biểu thức chính quy trong các tệp cấu hình CI. Nguyên nhân gốc rễ nằm ở Onigmo, engine biểu thức chính quy được nhúng trong Ruby. GitLab đã phát hành các phiên bản được vá lỗi vào ngày 12 tháng 10, nhưng các bản vá này yêu cầu phải cập nhật cụ thể cho runtime Ruby đi kèm thay vì sửa đổi mã ứng dụng của chính GitLab. Alpine Linux đã nhầm lẫn nâng cấp lên GitLab 19.3.4 thay vì phiên bản đã được khắc phục là 19.3.5 vào ngày 13 tháng 10, khiến instance của họ vẫn bị lộ.

Giữa ngày 20 và 21 tháng 10, một tài khoản mới đăng ký đã gửi các cấu hình CI được thiết kế tinh vi nhằm kích hoạt lỗ hổng. Các payload này đã làm sập tám lần các tiến trình worker của GitLab. Trong bốn trường hợp, kẻ tấn công đã tiến hành một phần chuỗi khai thác trước khi thất bại ở bước tiếp theo. Kẻ tấn công cũng tải xuống image container của GitLab, có thể để điều chỉnh phương pháp khai thác phù hợp với môi trường build cụ thể. Mặc dù đội ngũ không quan sát thấy dấu hiệu nào của việc thực thi mã độc thành công, chẳng hạn như các tệp bất thường hoặc sự chậm trễ trong xử lý, họ thừa nhận rằng một cuộc khai thác thành công sẽ không để lại dấu vết trong các log web tiêu chuẩn.

Việc phản hồi trở nên phức tạp hơn khi bản nâng cấp GitLab 19.3.6 vào ngày 22 tháng 10 không giải quyết được lỗ hổng. Do image container của Alpine sử dụng Ruby tiêu chuẩn thay vì bundle Ruby đã được vá của GitLab, lỗ hổng cơ bản vẫn tồn tại cho đến khi chính Ruby phát hành bản vá trong các phiên bản 3.3.13, 3.4.12 và 4.0.9 vào ngày 23 tháng 10. Khi đội ngũ nhận ra instance của họ vẫn dễ bị tổn thương vào ngày 26 tháng 10, họ đã đóng quyền truy cập đối với tất cả mọi người ngoại trừ các nhà phát triển và bắt đầu quá trình xây dựng lại toàn bộ.

Cơ chế hoạt động

Lỗ hổng này khai thác cách mà các biểu thức chính quy được xử lý bởi engine Onigmo trong Ruby. Khi GitLab phân tích cú pháp các tệp cấu hình CI, nó biên dịch các biểu thức chính quy này. Nếu kẻ tấn công cung cấp một mẫu được tạo ra độc hại, nó có thể khiến engine hoạt động không dự đoán được, tiềm ẩn nguy cơ cho phép thực thi mã từ xa. Đây không phải là lỗi trong logic nghiệp vụ của GitLab mà là lỗi trong runtime ngôn ngữ nền tảng mà nó phụ thuộc vào.

Đối với các instance tự lưu trữ, điều này tạo ra một chuỗi phụ thuộc phức tạp. Việc chỉ cập nhật ứng dụng GitLab là không đủ nếu môi trường host sử dụng cài đặt Ruby toàn hệ thống chưa được vá. Các gói chính thức của GitLab bao gồm một phiên bản Ruby đã được vá, nhưng các deployment tùy chỉnh hoặc image container dựa trên Ruby upstream phải chờ các nhà duy trì ngôn ngữ phát hành bản vá. Trong trường hợp này, bản vá xuất hiện trong các phiên bản Ruby vào ngày 23 tháng 10, hơn một tuần sau bản vá ban đầu của GitLab.

Chi tiết chính

• Lỗ hổng: CVE-2026-97229 (CVSS 10.0) trong engine regex Onigmo của Ruby.
• Cửa sổ tấn công: Ngày 20–21 tháng 10, với các nỗ lực tiếp diễn vào ngày 25–26 tháng 10.
• Tác động: Tám lần sập worker; không có xác nhận về rò rỉ dữ liệu, nhưng được coi là đã bị xâm phạm.
• Thất bại trong giảm thiểu: Nâng cấp GitLab lên 19.3.6 không khắc phục được vấn đề vì Ruby nền tảng chưa được vá.
• Xác minh: Các bản phát hành và gói của Alpine từ ngày 20–24 tháng 10 đã được đối chiếu với hồ sơ bên ngoài và xác nhận là không bị giả mạo.
• Phản hồi: Xây dựng lại toàn bộ instance, đặt lại mật khẩu và triển khai ghi log kết nối outbound.

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

Sự cố này làm nổi bật một điểm mù quan trọng trong việc quản lý hạ tầng tự lưu trữ: sự khác biệt giữa các bản vá cấp độ ứng dụng và các bản sửa lỗi cấp độ runtime. Các nhà phát triển thường giả định rằng việc nâng cấp gói phần mềm chính sẽ giải quyết mọi rủi ro bảo mật liên quan. Tuy nhiên, khi các lỗ hổng tồn tại trong các dependency dùng chung như Ruby, Python hoặc Node.js, lộ trình khắc phục bị phân mảnh. Các đội ngũ phải theo dõi các bản vá qua nhiều lớp, bao gồm runtime ngôn ngữ, các gói hệ điều hành và chính ứng dụng.

Đối với các trưởng nhóm kỹ thuật, điều này nhấn mạnh tầm quan trọng của việc xác minh thành phần của các image container và artifact deployment. Việc dựa vào các gói hệ thống mặc định có thể gây ra độ trễ giữa bản vá của nhà cung cấp và tư thế bảo mật của môi trường của bạn. Ngoài ra, việc thiếu ghi log mạng outbound đã cản trở quá trình điều tra, chứng tỏ rằng khả năng hiển thị đối với lưu lượng egress cũng quan trọng như giám sát ingress để phát hiện các hoạt động exfiltration hoặc command-and-control.

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

• Kiểm tra phiên bản Ruby của bạn ngay lập tức; đảm bảo bạn đang chạy phiên bản 3.3.13, 3.4.12, 4.0.9 hoặc mới hơn nếu bạn sử dụng GitLab.
• Kiểm tra các image container GitLab của bạn; nếu bạn đã kéo alpinelinux/gitlab:19.3.6 trước ngày 27 tháng 10, hãy kéo lại để có phiên bản Ruby đã được vá.
• Kiểm toán các pipeline CI/CD của bạn để tìm bất kỳ thay đổi gần đây hoặc job thất bại nào có thể chỉ ra các nỗ lực thăm dò.
• Bật ghi log cho các kết nối mạng outbound từ máy chủ CI và host cơ sở dữ liệu của bạn để cải thiện khả năng phản hồi sự cố.
• Đặt lại tất cả mật khẩu và xoay vòng các secret, bao gồm biến CI/CD và token runner, nếu bạn nghi ngờ có sự lộ thông tin.
• Triển khai các tag phát hành được ký kết cho các artifact nội bộ của bạn để cho phép xác minh độc lập về tính toàn vẹn của build.