GitLab vá lỗ hổng thực thi mã từ xa nghiêm trọng không cần xác thực

GitLab đã phát hành các bản vá bảo mật khẩn cấp cho phiên bản Community và Enterprise để khắc phục một lỗ hổng có mức độ nghiêm trọng tối đa, cho phép kẻ tấn công chưa xác thực thực thi mã tùy ý trên các máy chủ bị ảnh hưởng. Công ty đã công bố cảnh báo vào thứ Hai, ngày 13 tháng 10 năm 2026, kêu gọi quản trị viên của các instance tự host (self-hosted) nâng cấp ngay lập tức để ngăn chặn nguy cơ máy chủ bị xâm phạm.

Chuyện gì đã xảy ra

Lỗ hổng chính, được theo dõi với mã CVE-2026-97229, mang điểm số Hệ thống Đánh giá Lỗ hổng Chung (CVSS) hoàn hảo là 10.0. Xếp hạng này chỉ ra mức độ nghiêm trọng cao nhất có thể, nghĩa là lỗ hổng dễ khai thác và không yêu cầu tương tác hay xác thực từ người dùng. GitLab giải thích rằng vấn đề bắt nguồn từ việc kiểm tra không đầy đủ các biểu thức chính quy trong cấu hình CI/CD. Trong những điều kiện cụ thể, kẻ tấn công có thể tạo ra một biểu thức chính quy độc hại gây ra lỗi tràn số nguyên, cuối cùng cho phép chúng chạy các lệnh tùy ý trên máy chủ host.

Ngoài lỗ hổng nghiêm trọng này, GitLab cũng đã xử lý ba lỗi có mức độ nghiêm trọng cao trong cùng một bản phát hành. Bao gồm một lỗ hổng cross-site scripting (CVE-2026-92883) có thể cho phép người dùng đã xác thực thực thi JavaScript trong phiên trình duyệt của người dùng khác, và một lỗi ủy quyền không đúng cách (CVE-2026-16301) cho phép nhà phát triển chạy pipeline trên các nhánh được bảo vệ. Một vấn đề thứ ba (CVE-2026-14814) liên quan đến các biểu thức chính quy quá lỏng lẻo có thể làm ô nhiễm phản hồi được lưu trữ cache cho các tệp thô của repository, tiềm ẩn nguy cơ lộ các biến môi trường được bảo vệ trong quá trình thực thi pipeline.

Các bản vá hiện đã có sẵn trong các phiên bản 19.4.2, 19.3.5 và 19.2.8. Bất kỳ instance nào đang chạy các phiên bản cũ hơn trong các dòng phát hành 19.2, 19.3 hoặc 19.4 đều được coi là dễ bị tổn thương và yêu cầu nâng cấp ngay lập tức. Việc công bố này tiếp nối xu hướng các vấn đề bảo mật nghiêm trọng gần đây trên nền tảng, bao gồm một lỗ hổng CVSS 9.9 trong AI Gateway đã được khắc phục vài tuần trước đó và một lỗ hổng CVSS 10.0 khác vào tháng trước, vốn đã chứng kiến các hoạt động thăm dò tích cực trong thực tế ngay sau khi công khai.

Chi tiết chính

• Lỗ hổng nghiêm trọng: CVE-2026-97229 là một lỗ hổng CVSS 10.0 cho phép thực thi mã từ xa không cần xác thực thông qua các biểu thức chính quy được tạo thủ công trong cấu hình CI/CD.
• Phiên bản bị ảnh hưởng: Tất cả các phiên bản GitLab CE và EE từ 19.2 trở về trước 19.2.8, từ 19.3 trở về trước 19.3.5 và từ 19.4 trở về trước 19.4.2 đều bị ảnh hưởng.
• Nguyên nhân gốc rễ: Vấn đề được mô tả là lỗi tràn số nguyên do kiểm tra biểu thức chính quy không đầy đủ.
• Các sửa chữa bổ sung: Ba lỗi nghiêm trọng cao đã được vá, bao gồm cross-site scripting, ủy quyền không đúng cách trong việc tạo pipeline và ô nhiễm cache thông qua regex.
• Bối cảnh gần đây: Bản vá này tiếp nối hai lỗ hổng nghiêm trọng khác được công bố trong những tháng trước đó, một liên quan đến AI Gateway và một khác với các cuộc thăm dò tích cực trong thực tế.
• Khắc phục: Quản trị viên phải nâng cấp lên 19.4.2, 19.3.5 hoặc 19.2.8 để giải quyết các vấn đề này.

Bối cảnh chung

Thực thi mã từ xa (RCE) là một trong những loại lỗ hổng phần mềm nguy hiểm nhất vì nó cho phép kẻ tấn công giành toàn quyền kiểm soát máy chủ nền tảng. Khi một lỗ hổng được dán nhãn "không cần xác thực", điều đó có nghĩa là kẻ tấn công không cần tên đăng nhập hoặc mật khẩu hợp lệ để khai thác nó, làm giảm đáng kể rào cản gia nhập đối với các tác nhân độc hại. Điểm CVSS 10.0 đại diện cho kịch bản tồi tệ nhất về khả năng khai thác và tác động.

Biểu thức chính quy (regex) là các mẫu được sử dụng để khớp các tổ hợp ký tự trong chuỗi. Chúng được sử dụng rộng rãi trong lập trình cho việc kiểm tra dữ liệu và các thao tác tìm kiếm. Tuy nhiên, các mẫu regex phức tạp hoặc được kiểm tra kém đôi khi có thể dẫn đến hành vi không mong muốn, chẳng hạn như lỗi tràn số nguyên hoặc điều kiện từ chối dịch vụ. Trong trường hợp này, sự thiếu vắng kiểm tra phù hợp đã cho phép một đầu vào được tạo thủ công vượt qua các bước kiểm tra an toàn và kích hoạt việc thực thi mã trên máy chủ hosting instance GitLab.

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

Đối với các nhóm tự host GitLab, lỗ hổng này đại diện cho mối đe dọa trực tiếp đối với tính toàn vẹn của hạ tầng. Vì việc khai thác không yêu cầu xác thực, bất kỳ instance GitLab nào kết nối internet đang chạy phiên bản dễ bị tổn thương đều có nguy cơ bị xâm phạm bởi các scanner tự động hoặc kẻ tấn công nhắm mục tiêu. Khai thác thành công có thể dẫn đến đánh cắp dữ liệu, triển khai ransomware hoặc sử dụng máy chủ làm điểm xoay vòng cho các cuộc tấn công mạng sâu hơn. Thực tế rằng các lỗ hổng nghiêm trọng gần đây đã chứng kiến các hoạt động thăm dò tích cực cho thấy các tác nhân đe dọa đang giám sát chặt chẽ các công bố bảo mật của GitLab để tìm kiếm mục tiêu dễ dàng.

Các lỗi nghiêm trọng cao bổ sung nhấn mạnh sự phức tạp trong việc bảo mật các nền tảng DevOps hiện đại. Các vấn đề như ô nhiễm cache và ủy quyền không đúng cách trong pipeline CI/CD có thể âm thầm phá vỡ các biện pháp kiểm soát bảo mật, tiềm ẩn nguy cơ rò rỉ bí mật hoặc cho phép thay đổi trái phép các nhánh được bảo vệ. Đối với trưởng nhóm IT và kỹ sư DevOps, điều này củng cố nhu cầu về các quy trình quản lý bản vá nghiêm ngặt. Việc dựa vào lịch trình cập nhật mặc định có thể khiến hệ thống bị phơi bày quá lâu khi các lỗ hổng có mức độ nghiêm trọng tối đa được công bố.

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

• Kiểm tra phiên bản: Ngay lập tức xác minh phiên bản GitLab CE hoặc EE nào đang chạy trên máy chủ của bạn. Nếu nó cũ hơn 19.2.8, 19.3.5 hoặc 19.4.2, hãy lên kế hoạch cho một đợt nâng cấp khẩn cấp.
• Áp dụng bản vá: Nâng cấp lên phiên bản sửa lỗi mới nhất (19.4.2, 19.3.5 hoặc 19.2.8) càng sớm càng tốt. Kiểm thử việc nâng cấp trong môi trường staging nếu khả thi, nhưng ưu tiên tốc độ do tính chất nghiêm trọng của lỗ hổng.
• Hạn chế truy cập: Nếu không thể vá ngay lập tức, hãy cân nhắc hạn chế truy cập mạng vào instance GitLab chỉ dành cho các địa chỉ IP tin cậy, giảm bề mặt tấn công cho các khai thác không cần xác thực.
• Kiểm toán cấu hình CI/CD: Xem xét các pipeline CI/CD hiện có để tìm các biểu thức chính quy bất thường hoặc phức tạp có thể dễ mắc phải các vấn đề kiểm tra tương tự, ngay cả sau khi đã vá.
• Giám sát nhật ký: Tăng cường giám sát các hoạt động đáng ngờ, chẳng hạn như các lần thực thi quy trình không mong muốn hoặc lưu lượng outbound bất thường, điều có thể chỉ ra nỗ lực khai thác thành công.
• Xem xét các công bố gần đây: Hãy cập nhật thông tin về các cảnh báo bảo mật GitLab gần đây, xét đến tần suất của các vấn đề nghiêm trọng, và đảm bảo nhóm của bạn có quy trình phản ứng nhanh với các lỗ hổng nghiêm trọng cao trong tương lai.