CVE-2026-85706, một lỗ hổng path traversal đạt điểm CVSS 10.0 trong GitLab Community Edition và Enterprise Edition, đã được CISA đưa vào danh mục Known Exploited Vulnerabilities (KEV). Các máy chủ GitLab tự quản trị chưa vá có thể bị kẻ tấn công không cần xác thực đọc tệp tùy ý, từ đó làm lộ thông tin đăng nhập, khóa bí mật và dữ liệu cấu hình.
GitLab tự quản trị đang trở thành mục tiêu của hoạt động dò quét và khai thác trên Internet. Ảnh: The Hacker News
Lỗ hổng nằm ở đâu?
Theo thông báo của GitLab, nguyên nhân là cơ chế giới hạn đường dẫn không đúng kết hợp với việc thiếu kiểm tra xác thực trong repository commits API. Trong điều kiện có ít nhất một dự án công khai, một yêu cầu HTTP được tạo đặc biệt có thể vượt khỏi phạm vi tệp dự kiến và đọc nội dung trên máy chủ.
Phạm vi ảnh hưởng gồm GitLab CE và EE từ phiên bản 18.7 đến trước 19.1.8, nhánh 19.2 trước 19.2.6 và nhánh 19.3 trước 19.3.2. GitLab đã phát hành các bản 19.1.8, 19.2.6 và 19.3.2 để khắc phục; quản trị viên nên nâng cấp lên bản vá tương ứng hoặc mới hơn.
Từ công bố đến khai thác thực tế
GitLab công bố bản vá ngày 10/9/2026. Chỉ trong vài giờ, watchTowr ghi nhận các hoạt động dò quét trên Internet từ khoảng 06:00 UTC ngày 11/9. Sau đó, CISA xác nhận lỗ hổng đang bị khai thác và bổ sung CVE-2026-85706 vào KEV, yêu cầu các cơ quan dân sự liên bang Mỹ hoàn tất xử lý trước ngày 14/9/2026.
Các quan sát tiếp theo cho thấy hoạt động đã chuyển từ thăm dò hành vi sang xác định hệ thống dễ tổn thương, khai thác thành công và lấy cắp tệp cấu hình. Một số tác nhân được ghi nhận tìm kiếm bí mật trong cấu hình GitLab và thông tin SSH của máy chủ.
Vì sao rủi ro đặc biệt nghiêm trọng?
GitLab thường lưu trữ mã nguồn, biến CI/CD, token truy cập, khóa triển khai và thông tin kết nối tới hệ thống sản xuất. Việc đọc được tệp nhạy cảm không chỉ gây rò rỉ dữ liệu mà còn có thể mở đường cho chiếm tài khoản, truy cập máy chủ, sửa pipeline hoặc đầu độc thành phần phần mềm được phân phối xuống chuỗi cung ứng.
Điểm CVSS 10.0 phản ánh tổ hợp nguy hiểm: khai thác từ xa, không cần tài khoản và tác động tiềm tàng lớn. Các phiên bản self-managed công khai trên Internet cần được ưu tiên cao nhất; GitLab.com do nhà cung cấp quản lý không yêu cầu khách hàng tự thực hiện cập nhật máy chủ.
Khuyến nghị cho quản trị viên
- Nâng cấp ngay lên GitLab 19.3.2, 19.2.6, 19.1.8 hoặc bản mới hơn phù hợp với nhánh đang sử dụng.
- Nếu chưa thể vá, hạn chế truy cập Internet vào GitLab và vô hiệu hóa dự án công khai khi không thực sự cần thiết.
- Rà soát nhật ký đối với các yêu cầu HTTP POST tới đường dẫn
/api/v4/projects/{id}/repository/commits/có tham số liên quan đếnfile.path. - Luân chuyển token, khóa SSH, mật khẩu và bí mật CI/CD nếu phát hiện dấu hiệu đọc tệp hoặc truy cập bất thường.
- Kiểm tra lịch sử pipeline, runner và thay đổi mã nguồn nhằm phát hiện hành vi duy trì quyền truy cập hoặc đầu độc chuỗi cung ứng.
Bài học cho tổ chức
Tốc độ từ công bố đến dò quét và khai thác cho thấy cửa sổ vá lỗi đối với nền tảng DevOps công khai ngày càng ngắn. Tổ chức cần duy trì kiểm kê phiên bản, cảnh báo KEV, quy trình vá khẩn cấp và khả năng luân chuyển bí mật nhanh. Việc phân tách GitLab khỏi hệ thống sản xuất và giới hạn quyền của token cũng giúp giảm hậu quả nếu một lớp phòng vệ bị vượt qua.
VNCyberS tổng hợp từ GitLab, CISA, BleepingComputer, The Hacker News và watchTowr
Tiếng Việt
English