Ngày 28/10/2026, Alpine Linux công bố báo cáo hậu kiểm về các đợt tấn công nhắm vào máy chủ GitLab tự host của dự án. Điểm CVSS 10.0 là chi tiết gây chú ý, nhưng bài học đáng giá hơn nằm ở một điểm mù trong cách vá lỗi: khi bạn tự cung cấp runtime, bản vá của nhà phát triển có thể không bao giờ chạm tới đoạn mã đang thực sự bị lỗi.
Lỗ hổng mức tối đa, rồi một cuộc tấn công thật
CVE-2026-97229 là lỗ hổng thực thi mã từ xa không cần xác thực, có điểm CVSS 10.0 và được phân loại là lỗi tràn số nguyên (CWE-190). Lỗi được nhà nghiên cứu joaxcar báo cáo qua chương trình HackerOne Bug Bounty của GitLab. Ngày 12/10, GitLab phát hành các bản đã vá 19.2.8, 19.3.5 và 19.4.2 cho cả phiên bản Community lẫn Enterprise. GitLab.com và GitLab Dedicated được nhà cung cấp vá sẵn, khách hàng không cần làm gì thêm.
Tám ngày sau, trong hai ngày 20 và 21/10, kẻ tấn công tạo tài khoản mới trên máy chủ GitLab của Alpine rồi gửi lên các cấu hình CI độc hại. Alpine không phải mục tiêu ngẫu nhiên. Các gói của dự án nằm bên dưới vô số container image, nên hạ tầng build của Alpine là miếng mồi hấp dẫn với bất kỳ ai muốn đầu độc chuỗi cung ứng phần mềm.
Lỗi nằm bên dưới GitLab
CVE mang tên GitLab, nhưng đoạn mã lỗi thật ra nằm trong Onigmo, bộ máy xử lý biểu thức chính quy (regex engine) tích hợp sẵn trong runtime Ruby.
GitLab cho phép người dùng viết quy tắc pipeline trong tệp .gitlab-ci.yml có dùng regex, chẳng hạn để quyết định nhánh, tag hay trigger nào sẽ khởi chạy một job. Máy chủ phải biên dịch các mẫu regex đó. Trong một số điều kiện nhất định, ví dụ khi đường dẫn chứa những chuỗi ký tự UTF-8 đặc biệt, việc biên dịch một mẫu không đáng tin cậy sẽ gây tràn số nguyên bên trong Onigmo. Lỗi tràn số làm hỏng bộ nhớ, và có thể cho phép kẻ tấn công chạy mã trên máy chủ dưới quyền tài khoản dịch vụ git.
Trên máy chủ tự quản có bật tự do đăng ký tài khoản hoặc cho phép tạo dự án công khai, kẻ tấn công không cần quyền cao nào từ trước. Chỉ một tài khoản vừa tạo là đủ để chạm tới bộ phân tích CI.
Bài học kiến trúc ở đây khá khó chịu. Một tính năng vốn chỉ để quyết định có chạy job hay không lại chuyển văn bản do kẻ tấn công kiểm soát vào một thành phần C cấp thấp mà chính kỹ sư GitLab không viết ra.
Vì sao nâng cấp GitLab vẫn chưa bịt được lỗ hổng
Đây là phần đáng đọc nhất của báo cáo. Ngày 22/10, Alpine nâng GitLab lên 19.3.6, tức mới hơn cả bản đã vá 19.3.5. Theo báo cáo hậu kiểm, máy chủ vẫn còn hở.
Nguyên nhân nằm ở cách đóng gói. Các gói Omnibus và container image chính thức của GitLab đóng kèm một bản Ruby riêng, và bản vá được đưa vào chính bản Ruby đóng kèm đó. Alpine lại chạy GitLab trên Ruby hệ thống tiêu chuẩn của bản phân phối. Vì vậy, số phiên bản GitLab mới hơn không làm thay đổi đoạn mã Onigmo đang thực thi. Phải đến ngày 23/10, Ruby upstream mới phát hành bản vá ở các phiên bản 3.3.13, 3.4.12 và 4.0.9, tức khoảng 11 ngày sau bản phát hành của GitLab.
Những ai tự build GitLab từ mã nguồn, hoặc đóng gói nó trên base image tùy biến, đều rơi vào cùng khoảng hở này. Bảng theo dõi phiên bản ghi “đã vá”, còn tiến trình đang chạy trong bộ nhớ thì chưa.
Nên đưa một bước kiểm tra một dòng vào runbook vận hành. Hãy chạy lệnh này bên trong container GitLab hoặc trên máy chủ, đúng môi trường mà GitLab thực sự sử dụng:
ruby -e 'puts RUBY_VERSION'
Kết quả phải tối thiểu là 3.3.13, 3.4.12 hoặc 4.0.9 tùy nhánh. Nếu thấp hơn, việc nâng cấp GitLab một mình chưa bảo vệ được bạn.
Quy tắc chung khá đơn giản: bản vá bảo mật gắn với một thành phần cụ thể chứ không gắn với tên sản phẩm. Bạn cần biết thành phần nào mang bản vá, và bản build của mình có thật sự chứa thành phần đó hay không.
Điều đã hạn chế thiệt hại: khóa ký không bao giờ nằm trên máy chủ Git
Sự cố này lẽ ra có thể tệ hơn nhiều. Nếu các gói Alpine độc hại mang chữ ký hợp lệ, chúng sẽ trôi xuống hạ nguồn và đi vào vô số container. Rủi ro đó được chặn lại vì khóa ký gói của Alpine được lưu trữ hoàn toàn tách biệt khỏi máy chủ GitLab.
Nhiều đội kỹ thuật, trong đó có không ít startup Việt, lưu khóa ký bản phát hành hoặc thông tin xác thực deploy lên cloud ngay trong biến CI/CD cho tiện tự động hóa. Với cách cấu hình đó, máy chủ Git bị chiếm quyền đồng nghĩa với kênh phát hành bị chiếm quyền, kéo theo mọi secret, biến CI và runner token đang lưu trên đó.
Alpine tách nơi build mã khỏi nơi ký sản phẩm. Dù vậy, nhóm vẫn coi máy chủ là không còn đáng tin và dựng lại từ đầu. Đó là một bước tốn kém, nhưng nhỏ hơn rất nhiều so với một vụ xâm nhập lan ra cả hệ sinh thái.
Danh sách việc cần làm cho đội tự vận hành GitLab
Nếu bạn đang chạy GitLab tự host, báo cáo của Alpine gợi ý một thứ tự xử lý cụ thể:
- Vá cả hai lớp. Nâng GitLab lên 19.2.8, 19.3.5, 19.4.2 hoặc mới hơn, sau đó xác nhận Ruby mà GitLab đang chạy cũng đã được vá. Gói chính thức mang sẵn bản vá; image tự build phải được build lại trên Ruby đã vá.
- Kiểm kê thành phần runtime. Danh mục thành phần (BOM) của image cần liệt kê cả trình thông dịch và thư viện native, không chỉ phiên bản ứng dụng.
- Đóng tính năng tự do đăng ký và hạn chế quyền tạo dự án với các tài khoản ngoài tổ chức.
- Kiểm soát việc chạy CI từ những tài khoản và fork chưa qua xét duyệt.
- Dựng lại khi thấy dấu hiệu thăm dò. Coi dấu hiệu khai thác là lý do để dựng lại sạch từ đầu, chứ không chỉ vá nhanh rồi cho qua.
- Đưa khóa ký ra khỏi CI và chuyển việc ký sang một bước riêng, tối giản.
Tự host GitLab vẫn là lựa chọn hợp lý nếu bạn cần kiểm soát dữ liệu và chi phí. Cái giá phải trả là bạn trở thành người tích hợp mọi lớp bên dưới, chứ không còn đơn thuần là khách hàng của GitLab. Nếu đội của bạn không theo dõi được runtime sát sao như theo dõi ứng dụng, dùng gói chính thức của nhà phát triển là lựa chọn an toàn hơn.
Đang tải bình luận…