GitLab vá khẩn cấp các lỗ hổng đe dọa tới hệ thống toàn cầu

[WhiteHat Team]

GitLab, nền tảng quản lý mã nguồn và DevOps nổi tiếng toàn cầu vừa phát hành một loạt bản cập nhật bảo mật khẩn cấp nhằm khắc phục nhiều lỗ hổng nguy hiểm có thể bị khai thác để tấn công vào hệ thống của hàng triệu người dùng.

Hàng loạt lỗ hổng nghiêm trọng, bao gồm cả tấn công giả mạo máy chủ (SSRF), từ chối dịch vụ (DoS) và rò rỉ thông tin. Các lỗi bảo mật này ảnh hưởng trực tiếp đến hàng triệu người dùng và tổ chức đang tự triển khai GitLab trên hạ tầng riêng, bao gồm cả phiên bản Community Edition (CE) và Enterprise Edition (EE).

"GitLab[.]com" (dịch vụ do GitLab trực tiếp vận hành) và khách hàng sử dụng GitLab Dedicated không bị ảnh hưởng, do các hệ thống này đã được cập nhật trước đó. Tuy nhiên, đối với các doanh nghiệp và tổ chức đang vận hành GitLab theo hình thức tự quản lý (self-managed), việc cập nhật lên các bản vá mới nhất là bắt buộc nếu không muốn trở

Lỗ hổng được đánh giá nghiêm trọng nhất trong đợt vá lần này mang mã định danh CVE-2025-6454. Đây là một lỗ hổng thuộc nhóm tấn công SSRF (Server-Side Request Forgery), cho phép tin tặc gửi các yêu cầu từ chính máy chủ GitLab tới các địa chỉ nội bộ hoặc dịch vụ nhạy cảm, vượt qua các lớp bảo mật thông thường.

• Mức độ nguy hiểm: Cao - CVSS 8,5
• Ảnh hưởng: Các phiên bản từ 16.11 đến trước 18.3.2.
• Chi tiết: Lỗi trong tính năng Webhook custom header cho phép người dùng được xác thực có thể tạo yêu cầu truy cập nội bộ trái phép từ chính máy chủ GitLab. Điều này mở đường cho các cuộc tấn công truy cập tài nguyên nội bộ mà bình thường không thể tiếp cận từ bên ngoài.

Ngoài SSRF, GitLab cũng vá nhiều lỗ hổng DoS có mức độ ảnh hưởng cao. Đáng chú ý là CVE-2025-2256, liên quan đến việc xử lý các phản hồi SAML có dung lượng lớn. Nếu không được kiểm soát, một phản hồi xác thực bất thường có thể khiến hệ thống tiêu tốn toàn bộ tài nguyên để xử lý, dẫn đến việc các tiến trình nền bị đình trệ.

Một lỗ hổng khác là CVE-2025-1250, cho phép người dùng chèn nội dung lớn hoặc độc hại vào các trường như mô tả Merge Request, commit message hoặc bình luận. Những hành động tưởng chừng bình thường này lại có thể khiến hệ thống quá tải và ngừng hoạt động, đặc biệt khi bị lạm dụng có chủ đích.

Tương tự, hai lỗ hổng khác là CVE-2025-7337 và CVE-2025-10094 cho phép kẻ tấn công gửi các yêu cầu tải file quá lớn hoặc đặt tên token dài bất thường nhằm gây tiêu tốn bộ nhớ và tài nguyên xử lý. Đáng lo ngại hơn, những lỗi này không đòi hỏi quyền quản trị, tức là bất kỳ người dùng nào có quyền truy cập nhất định cũng có thể vô tình hoặc cố ý khai thác để làm tê liệt hệ thống.

CVE-2025-6769 là một lỗ hổng ở mức độ trung bình, nhưng vẫn đáng chú ý vì liên quan đến việc tiết lộ thông tin bảo trì hệ thống chỉ dành cho quản trị viên. Lỗi này nằm ở các endpoint của GitLab Runner – công cụ CI/CD thường được cấu hình để chạy tự động. Nếu bị lạm dụng, người dùng không có quyền admin có thể xem được các thông tin hệ thống nhạy cảm, từ đó phục vụ cho các cuộc tấn công tiếp theo.

Lỗ hổng​	Mô tả​	Mức độ nguy hiểm​	CVSS​
CVE-2025-6454​	SSRF qua Webhook header​	Nguy hiểm cao​	8.5​
CVE-2025-2256​	DoS qua phản hồi SAML lớn​	Cao​	7.5​
CVE-2025-1250​	DoS qua commit/message​	Trung bình​	6.5​
CVE-2025-7337​	DoS qua upload file​	Trung bình​	6.5​
CVE-2025-10094​	DoS qua tên token dài​	Trung bình​	6.5​
CVE-2025-6769​	Rò rỉ thông tin runner​	Trung bình​	4.3​

Hầu hết các lỗ hổng lần này đều xuất phát từ việc xử lý dữ liệu đầu vào không an toàn hoặc lạm dụng các chức năng vốn được thiết kế hợp pháp như webhook, xác thực SAML hoặc tính năng CI/CD. Điểm chung là các thành phần này thường được cấu hình linh hoạt để phục vụ quá trình phát triển phần mềm nhanh chóng, nhưng lại dễ trở thành mục tiêu nếu không có lớp kiểm soát bảo mật phù hợp.

Thực tế cho thấy, nhiều tổ chức đang sử dụng GitLab trong mô hình nội bộ, không kết nối internet và thường bỏ qua cập nhật vì lo ngại gián đoạn. Điều này vô tình tạo ra những “cánh cửa mở” cho kẻ xấu, đặc biệt khi GitLab là trung tâm của toàn bộ quy trình phát triển phần mềm, tích hợp hệ thống và phân phối ứng dụng.

Các lỗ hổng được xác định ảnh hưởng đến tất cả các phiên bản GitLab CE và EE kể từ bản 7.8 trở đi (đối với lỗi tải file), 7.12 trở đi (đối với lỗi xác thực SAML), cho đến trước các bản vá mới nhất là 18.1.6, 18.2.6 và 18.3.2.

Điều này đồng nghĩa với việc hầu hết các hệ thống GitLab đang tự triển khai trên toàn thế giới, bao gồm: Các doanh nghiệp phần mềm, ngân hàng, tổ chức chính phủ, startup công nghệ... có thể đều nằm trong diện bị ảnh hưởng nếu chưa cập nhật. Tại Việt Nam, nhiều tổ chức trong lĩnh vực fintech, thương mại điện tử, dịch vụ IT outsourcing và startup cũng đang sử dụng GitLab nội bộ, đặt ra yêu cầu cấp thiết về việc kiểm tra và cập nhật hệ thống.

Các chuyên gia khuyến cáo:
1. Cập nhật ngay lập tức các bản vá bảo mật sau:

• Nếu đang dùng các phiên bản:
  • 18.3 → cập nhật lên 18.3.2
  • 18.2 → cập nhật lên 18.2.6
  • 18.1 → cập nhật lên 18.1.6
• Các phiên bản cũ hơn cần nâng cấp lên bản mới nhất trước khi áp dụng vá.

2. Kiểm tra và cập nhật GitLab Runner

• Hệ thống CI/CD chạy các job từ mã nguồn cũng cần được cập nhật để tránh lỗ hổng rò rỉ thông tin.

3. Không cần downtime cho hệ thống lớn

• Với các triển khai đa máy chủ, GitLab cho biết không cần ngừng dịch vụ để cập nhật và có thể dùng tùy chọn bỏ qua cấu hình lại tự động để đảm bảo tính liên tục.

4. Thực hiện kiểm tra bảo mật định kỳ

• Xem xét lại chính sách Webhook, quyền người dùng, cấu hình CI/CD.
• Áp dụng các thực hành an ninh do GitLab khuyến nghị, bao gồm: Cứng hóa máy chủ, giám sát truy cập và mã hóa.

Cuộc chiến an ninh mạng chưa bao giờ dừng lại. Ngay cả những hệ thống mã nguồn mở nổi tiếng, được hàng triệu người sử dụng như GitLab, cũng có thể bị tấn công nếu không kịp thời cập nhật. Đừng để một bản vá bị trì hoãn trở thành nguyên nhân dẫn đến sự cố an ninh nghiêm trọng, làm gián đoạn sản xuất và tổn thất tài chính không thể đo đếm được.

WhiteHat​