CVE-2026-85706 trên GitLab bị dò quét: Cập nhật ngay

CVE-2026-85706 trên GitLab có điểm CVSS 10.0 và đã xuất hiện hoạt động dò quét ngoài Internet chỉ vài giờ sau khi công bố. Lỗi cho phép người chưa đăng nhập đọc tệp tùy ý trên máy chủ GitLab trong một số điều kiện. Nếu đang tự vận hành GitLab Community Edition hoặc Enterprise Edition, việc cần làm sáng nay khá gọn: kiểm tra phiên bản và nâng cấp ngay.

GitLab công bố bản vá ngày 10/9/2026. watchTowr cho biết họ bắt đầu thấy hoạt động dò quét từ 06:00 UTC ngày 11/9. Dò quét chưa đồng nghĩa mọi yêu cầu đều đã chiếm được máy chủ, nhưng nó cho thấy thời gian chần chừ gần như đã hết.

CVE-2026-85706 nguy hiểm ở điểm nào?

Lỗ hổng nằm trong API xử lý commit của kho mã. GitLab mô tả nguyên nhân là đường dẫn tệp không được giới hạn đúng phạm vi, đồng thời thiếu kiểm tra xác thực. Nói dễ hiểu, kẻ tấn công có thể yêu cầu API đi ra ngoài thư mục được phép và đọc tệp mà dịch vụ GitLab có quyền truy cập.

Cuộc tấn công không cần tài khoản. Theo thông tin công khai hiện có, điều kiện đáng chú ý là máy chủ có ít nhất một dự án public. Tệp bị lộ có thể chứa cấu hình GitLab, nhật ký, token, khóa SSH hoặc thông tin đăng nhập. Mức thiệt hại thực tế phụ thuộc quyền của tiến trình GitLab và cách từng hệ thống được cấu hình.

Đây là lỗi đọc tệp, không nên tự động diễn giải thành “đã có quyền root”. Tuy vậy, bí mật lấy được từ máy chủ quản lý mã nguồn và quy trình CI/CD có thể mở đường sang kho mã, runner, registry hoặc hạ tầng đám mây. Đọc nhầm một tệp ở máy cá nhân đã phiền; đọc được tệp bí mật trên hệ thống build thì câu chuyện nhanh chóng bớt vui.

Phiên bản GitLab nào cần cập nhật?

CVE-2026-85706 ảnh hưởng 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. Các bản đã sửa là 19.1.8, 19.2.6 và 19.3.2. Bản mới hơn thuộc nhánh được GitLab hỗ trợ cũng được chấp nhận.

GitLab.com đã chạy mã được vá. Khách hàng GitLab Dedicated không cần tự thao tác cho lỗi này. Cảnh báo chủ yếu dành cho các hệ thống self-managed, tức máy chủ do doanh nghiệp hoặc tổ chức tự cài và quản trị.

Việc nên làm ngay

1. Xác định mọi máy chủ GitLab self-managed, kể cả hệ thống thử nghiệm và máy chủ cũ đang “tạm để đó” nhưng vẫn mở Internet.
2. Kiểm tra phiên bản bằng giao diện quản trị hoặc lệnh quản lý gói phù hợp, sau đó nâng cấp lên 19.1.8, 19.2.6, 19.3.2 hoặc bản mới hơn theo hướng dẫn chính thức.
3. Nếu chưa thể vá ngay, hạn chế truy cập từ Internet và tạm chuyển dự án public sang phạm vi hẹp hơn. Đây chỉ là cách giảm rủi ro trong lúc chờ bảo trì, không thay thế bản vá.
4. Rà soát log HTTP cho các yêu cầu POST bất thường tới đường dẫn dạng /api/v4/projects/{id}/repository/commits/, nhất là yêu cầu có tham số file.Path. Không đưa log thô có token hay dữ liệu người dùng lên diễn đàn công khai.
5. Nếu thấy dấu hiệu khai thác, cô lập máy chủ để điều tra. Hãy thay token, khóa truy cập, mật khẩu và bí mật CI/CD có khả năng nằm trong tệp bị đọc. Vá phần mềm không làm các bí mật đã lộ tự quay về két.

Những đội đang vận hành kho gói phần mềm cũng nên xem lại cảnh báo CVE-2026-82329 trên JFrog Artifactory. Hai lỗi khác sản phẩm, nhưng cùng nhắc một việc: máy chủ giữ mã và gói build là mục tiêu có giá trị cao, không nên để bản vá xếp hàng như vé gửi xe.

Nguồn kiểm chứng

• GitLab Critical Patch Release 19.3.2, 19.2.6 và 19.1.8.
• watchTowr: Rapid Reaction về CVE-2026-85706, ngày 11/9/2026.
• BleepingComputer: GitLab kêu gọi cập nhật lỗi path traversal mức tối đa, ngày 11/9/2026.