Ngày 29 tháng 10 năm 2026, CISA đã thêm lỗ hổng CVE-2026-97229 của GitLab Community và Enterprise Edition vào danh mục Known Exploited Vulnerabilities (phiên bản danh mục 2026.10.29). Việc được đưa vào danh mục nghĩa là đã ghi nhận khai thác thực tế. Điều đó không có nghĩa mọi hệ thống đều bị xâm nhập, và CISA không nêu kẻ tấn công, quy mô hay khách hàng bị ảnh hưởng.
Điều này có liên quan đến website của bạn không?
GitLab là hạ tầng phát triển và triển khai phần mềm, không phải plugin WordPress. Một website công khai bình thường không hề cho thấy phía sau nó có GitLab hay không. Cảnh báo này đáng quan tâm khi công ty bạn, hoặc nhà cung cấp xây dựng và phát hành website cho bạn, tự vận hành GitLab để lưu mã nguồn, chạy pipeline build và deploy, hoặc cấp quyền phát hành.
GitLab đã công bố gì
Thông báo bản vá ngày 12 tháng 10 năm 2026 của GitLab mô tả lỗi thực thi mã không cần xác thực, trong một số điều kiện nhất định, qua biểu thức chính quy CI/CD được chế tác đặc biệt. GitLab.com và GitLab Dedicated đã được nhà cung cấp vá. Hệ thống tự quản lý cần các bản đã sửa dưới đây.
| Nhánh bị ảnh hưởng | Đã sửa ở |
|---|---|
| 19.2 trước 19.2.8 | 19.2.8 |
| 19.3 trước 19.3.5 | 19.3.5 |
| 19.4 trước 19.4.2 | 19.4.2 |
Để tham khảo thêm, đội ngũ Ruby đã giải thích ngày 23 tháng 10 năm 2026 rằng GitLab khắc phục các lỗi gốc trong trình biên dịch biểu thức chính quy Onigmo bằng cách vá bản Ruby đi kèm GitLab. Bài học thực tế là cập nhật CMS của website công khai không giúp gì cho GitLab tự quản lý. Đừng tự thay bản Ruby đi kèm. Hãy dùng gói do nhà cung cấp phát hành.
Danh sách kiểm tra cho chủ website
- Xác định có GitLab tự quản lý hay không. Hỏi nhà cung cấp về phiên bản CE hay EE, số phiên bản đã cài, nhánh được hỗ trợ đang chạy, nơi lưu trữ và tên người phụ trách việc vá lỗi.
- Với GitLab dạng SaaS do bên khác quản lý, yêu cầu xác nhận bằng văn bản rằng dịch vụ đã được vá. Đừng tự vá dịch vụ do nhà cung cấp vận hành.
- Để nhà cung cấp chọn gói đã vá hiện tại của nhánh được hỗ trợ và đi theo lộ trình nâng cấp của GitLab, thay vì hạ một hệ thống mới hơn xuống mức tối thiểu cũ. Trước mọi thay đổi được phê duyệt, xác nhận có bản sao lưu, bản sao cấu hình và sẵn sàng khôi phục. Bài chiến lược sao lưu của chúng tôi nói kỹ phần khôi phục.
- Yêu cầu rà soát có phạm vi rõ ràng các log GitLab hiện có đối chiếu với hướng dẫn phát hiện của GitLab, vì đã có báo cáo khai thác. Hỏi cụ thể về dấu hiệu bất thường trước đó, và xem việc log không có cảnh báo là một kết quả cần ghi nhận, không phải bằng chứng an toàn.
- Chỉ khi phát hiện dấu hiệu, hỏi xem thông tin xác thực của dự án, triển khai hay runner có cần điều tra không. Bảo toàn log trước. Thống nhất cách cô lập, khôi phục quyền truy cập và xử lý thông tin xác thực với nhà cung cấp đủ năng lực. Đừng mặc định thông tin xác thực đã bị đánh cắp hay yêu cầu đổi toàn bộ khi chưa có bằng chứng.
- Kiểm chứng luồng phát hành sau thay đổi. Bắt đầu bằng một lượt build và deploy có kiểm soát trong môi trường thử nghiệm được cấp phép, rồi thực hiện các bước kiểm tra tiêu biểu đã thống nhất trên website bằng dữ liệu giả lập, không phát sinh đơn hàng hay khoản thu thật.
- Lưu bằng chứng có ghi ngày: gói đã vá được cài, phạm vi rà soát, kết quả và những điểm còn chưa rõ, cùng kết quả kiểm chứng quy trình phát hành. Kết hợp với các tín hiệu trong bài giám sát không chỉ uptime.
Cảnh báo này không thể cho bạn biết điều gì
Bằng chứng đã vá không chứng minh được rằng trước đó không có gì xảy ra. Một website công khai trông bình thường không nói lên gì về mức độ an toàn của hệ thống phát hành phía sau. Hãy xem đây là cuộc trao đổi với người vận hành pipeline của bạn, không phải lý do để hoảng loạn hay tự thay đổi những gì bạn không nhìn thấy.
Kiểm tra tính đến ngày 30 tháng 10 năm 2026.