GitLab vá lỗi chạy lệnh trong CI: máy chủ đơn nút phải chấp nhận downtime

Ngày 26/8/2026, GitLab phát hành các phiên bản 19.3.1, 19.2.5 và 19.1.7 cho Community Edition (CE) và Enterprise Edition (EE). Thông báo bản vá của GitLab xác nhận CVE-2026-18252 có thể cho người dùng đã xác thực với quyền Developer chạy lệnh tùy ý trong ngữ cảnh CI; GitLab khuyến nghị các hệ thống Self-Managed bị ảnh hưởng nâng cấp ngay.

Trong đợt phát hành ngày 26/8/2026, cả ba phiên bản đều chứa migration cơ sở dữ liệu thông thường. Vì migration phải hoàn tất trước khi GitLab khởi động lại, máy chủ Self-Managed đơn nút bắt buộc có downtime; cụm nhiều nút chỉ có thể tránh gián đoạn khi đáp ứng quy trình nâng cấp zero-downtime.

CVE-2026-18252 chỉ ảnh hưởng GitLab EE

Lỗ hổng nằm trong Duo Claude AI agent của GitLab EE. Trong một số điều kiện, agent xử lý cấu hình lấy từ nguồn do người dùng kiểm soát, tạo khả năng để tài khoản có vai trò Developer thực thi lệnh tùy ý trong môi trường CI.

Phạm vi được công bố gồm GitLab EE từ 18.9 đến trước 19.1.7, nhánh 19.2 trước 19.2.5 và nhánh 19.3 trước 19.3.1. Hồ sơ CVE-2026-18252 trên OpenCVE ghi nhận trạng thái công bố, mức nghiêm trọng cao và ba mốc phiên bản khắc phục tương ứng.

Đây không phải lỗi cho phép một người dùng Internet chưa đăng nhập tự động chiếm máy chủ. Đánh giá của GitLab yêu cầu tài khoản có đặc quyền thấp và có tương tác của người dùng, nhưng tác động tiềm tàng đến tính bí mật và toàn vẹn đều ở mức cao. Quyền Developer vì thế không phải một ranh giới đủ để thay thế bản vá.

CE không thuộc phạm vi của CVE-2026-18252, song không nên bỏ qua toàn bộ đợt phát hành. Ba phiên bản này còn sửa CVE-2026-77801, một lỗi từ chối dịch vụ trong quá trình import pipeline ảnh hưởng cả CE và EE; quản trị viên CE vẫn cần đối chiếu bảng lỗi theo phiên bản đang vận hành.

Chọn bản vá theo edition, phiên bản và kiến trúc

Với GitLab EE, đích nâng cấp tối thiểu phụ thuộc vào nhánh hiện tại. Cảnh báo ngày 26/8 của CSIRT Toscana xác nhận phạm vi các nhánh bị ảnh hưởng và khuyến nghị cập nhật sản phẩm dễ bị tổn thương.

• EE từ 18.9 đến 19.1.6: nâng lên ít nhất 19.1.7 hoặc phiên bản mới hơn theo đường nâng cấp được hỗ trợ.
• EE 19.2.0–19.2.4: nâng lên ít nhất 19.2.5.
• EE 19.3.0: nâng lên 19.3.1 hoặc mới hơn.
• EE đã ở 19.1.7, 19.2.5 hoặc 19.3.1: không còn nằm dưới ngưỡng bị ảnh hưởng đã công bố cho CVE này.
• CE: không bị CVE-2026-18252 tác động, nhưng vẫn cần xử lý các lỗi CE/EE khác trong cùng bản phát hành.

Sau phiên bản, kiến trúc quyết định cách bố trí cửa sổ bảo trì. Tài liệu về lựa chọn downtime của GitLab quy định máy đơn phải nâng cấp có gián đoạn; người dùng có thể thấy thông báo đang triển khai hoặc lỗi 502. Hệ thống nhiều nút có thể chọn nâng cấp có hoặc không downtime.

Zero-downtime không phải thuộc tính tự động của mọi cụm nhiều nút. Phương án này cần nâng các nút theo thứ tự xác định, sử dụng cân bằng tải, thành phần HA và graceful reload. Nếu đường nâng cấp phải đi qua nhiều bản minor, GitLab yêu cầu đưa toàn bộ instance ngoại tuyến và thực hiện nâng cấp có downtime, kể cả khi hệ thống có nhiều nút.

Checklist cho cửa sổ bảo trì

Đội vận hành nên chốt phương án downtime trước khi bắt đầu thay đổi. Với máy đơn, gián đoạn là điều kiện của bản vá; với cụm nhiều nút, chỉ chọn zero-downtime sau khi xác nhận tải có thể chuyển khỏi từng nút và các thành phần thiết yếu có dự phòng.

1. Ghi lại edition, phiên bản hiện tại, phương thức cài đặt, topology, các thành phần Gitaly, PostgreSQL hoặc Redis bên ngoài và toàn bộ điểm dừng trên đường nâng cấp.
2. Lập kế hoạch rollback; sao lưu dữ liệu, secrets và tệp cấu hình. Nếu dùng snapshot cho hệ thống nhiều nút, snapshot phải bao phủ từng nút.
3. Chạy health check và xử lý lỗi trước khi thay đổi; chờ tất cả background migration hiện có hoàn tất trước mỗi bước nâng cấp.
4. Tạm dừng runner, chặn job mới và chờ job đang chạy kết thúc để tránh lỗi cập nhật trace hoặc tải artifact khi GitLab không sẵn sàng.
5. Thực hiện quy trình đúng với Linux package, Helm chart, GitLab Operator hoặc kiến trúc nhiều nút; không suy khả năng zero-downtime từ hướng dẫn dành cho mô hình khác.

Hướng dẫn chuẩn bị nâng cấp của GitLab yêu cầu xác định đường nâng cấp, lập kế hoạch backup và khôi phục, thử trên bản sao môi trường production khi có thể, đồng thời chạy health check ngay trước và sau thay đổi. Khi khôi phục backup, phiên bản GitLab đích phải khớp với phiên bản đã tạo bản sao.

Chỉ mở lại CI/CD sau khi kiểm tra toàn bộ cụm

Sau khi cài bản vá, cần xác nhận phiên bản thực tế trên mọi nút, không chỉ nút điều phối hoặc điểm truy cập qua bộ cân bằng tải. Các kiểm tra vận hành gồm đăng nhập, xem danh sách dự án, mở issue và merge request, clone repository, push commit, để runner nhận job, cùng thao tác đẩy và kéo image từ registry.

Luồng CI/CD chỉ nên hoạt động lại sau khi các kiểm tra chính đạt yêu cầu và migration đã ổn định. Với cụm nhiều nút, mọi vai trò dịch vụ phải được kiểm tra và không được để nút chạy phiên bản cũ tiếp tục nhận lưu lượng.

Trạng thái đã xác nhận của sự kiện là GitLab.com đã chạy phiên bản được vá, còn khách hàng GitLab Dedicated không phải tự thực hiện hành động này. Trọng tâm nâng cấp thuộc về GitLab Self-Managed: chọn ít nhất 19.1.7, 19.2.5 hoặc 19.3.1 theo nhánh, rồi xác định downtime từ topology và đường nâng cấp thực tế.

Đọc thêm:

• Hai SOC cùng bị chiếm domain, chỉ một bên phát hiện: công cụ không phải khác biệt
• Google Search Profile cần 35.000 follower, creator Việt vẫn phải chờ
• JetBrains Cadence bị xâm nhập: Khóa cloud và mã nguồn đều phải coi là lộ