top of page
Tìm kiếm

Lỗ hổng GitLab cho phép xóa project không cần đăng nhập

GitLab ngày 17/8/2026 phát hành bản vá khẩn cấp cho CVE-2026-19478, lỗ hổng Critical có điểm CVSS 9.4. Trong một số điều kiện, kẻ tấn công không cần đăng nhập vẫn có thể từ xa sửa hoặc xóa public project và dữ liệu người dùng trên GitLab CE/EE tự quản lý. GitLab yêu cầu các hệ thống bị ảnh hưởng nâng cấp ngay.

Một nền tảng quản lý mã nguồn có thể chứa code, lịch sử phát triển, project và nhiều dữ liệu quan trọng của doanh nghiệp. Vì vậy, khả năng một người bên ngoài can thiệp vào project mà không cần tài khoản tạo ra rủi ro đáng kể đối với tính toàn vẹn dữ liệu và quy trình phát triển phần mềm.

lo-hong-gitlab-cve-2026-19478
Cảnh báo lỗ hổng GitLab CVE-2026-19478

Lỗ hổng GitLab CVE-2026-19478 nguy hiểm như thế nào?

CVE-2026-19478 được GitLab xếp mức Critical, với điểm CVSS 9.4/10. GitLab xác nhận rằng trong một số điều kiện, người dùng chưa xác thực có thể từ xa sửa hoặc xóa public project và dữ liệu người dùng thông qua một GraphQL directive.

Đây là điểm khiến CVE-2026-19478 đáng chú ý đối với các hệ thống GitLab mở ra Internet. Kẻ tấn công không nhất thiết phải đánh cắp mật khẩu, vượt MFA hoặc chiếm một tài khoản GitLab trước khi tìm cách khai thác lỗi.

Tuy nhiên, cần tránh diễn giải quá mức. GitLab hiện xác nhận hậu quả là khả năng sửa hoặc xóa project công khai và dữ liệu người dùng; advisory không khẳng định CVE-2026-19478 cho phép thực thi mã tùy ý trên hệ điều hành hoặc chiếm toàn bộ máy chủ GitLab.

Những phiên bản GitLab nào đang bị ảnh hưởng?

Phạm vi ảnh hưởng bao gồm nhiều phiên bản GitLab CE và EE kể từ nhánh 18.2. GitLab đã phát hành bốn phiên bản vá gồm 18.11.11, 19.0.8, 19.1.6 và 19.2.4 vào ngày 17/8/2026.

Nhánh GitLab

Phiên bản bị ảnh hưởng

Phiên bản đã vá

GitLab 18.x

Từ 18.2 đến trước 18.11.11

18.11.11

GitLab 19.0

Trước 19.0.8

19.0.8

GitLab 19.1

Trước 19.1.6

19.1.6

GitLab 19.2

Trước 19.2.4

19.2.4

Đáng chú ý, chỉ năm ngày trước đợt vá Critical này, GitLab đã phát hành các phiên bản 19.2.2, 19.1.4 và 19.0.6 để xử lý 13 vấn đề bảo mật khác.

👉 IPSIP đã tổng hợp đợt cập nhật đó trong bài GitLab phát hành bản vá khẩn cấp cho 13 lỗ hổng bảo mật. Diễn biến liên tiếp cho thấy doanh nghiệp không nên xem việc đã cập nhật ở đợt trước là bằng chứng hệ thống hiện đã an toàn với CVE-2026-19478.

Kẻ tấn công có thể khai thác lỗi GraphQL này ra sao?

Chi tiết kỹ thuật đầy đủ hiện chưa được GitLab công khai. Vendor chỉ xác nhận CVE-2026-19478 liên quan đến một GraphQL directive, nhưng chưa nêu tên directive hoặc toàn bộ điều kiện cần thiết để khai thác.

GraphQL là cơ chế API cho phép client yêu cầu chính xác dữ liệu hoặc thao tác cần thực hiện. Trong GitLab, GraphQL được sử dụng để tương tác với nhiều đối tượng của nền tảng. Khi logic xử lý directive xuất hiện lỗi Code Injection, một request được xây dựng đặc biệt có thể dẫn tới hành vi mà ứng dụng không nên cho phép.

Điều có thể xác nhận ở thời điểm 19/8/2026 là:

  • khai thác có thể thực hiện từ xa qua mạng;

  • không yêu cầu tài khoản hoặc đặc quyền sẵn có;

  • không yêu cầu người dùng bấm link hay thực hiện thao tác;

  • có thể ảnh hưởng public project và dữ liệu người dùng;

  • GitLab chưa công bố chính xác điều kiện để cuộc tấn công thành công

Doanh nghiệp dùng GitLab Self-Managed cần làm gì ngay?

Doanh nghiệp nên bắt đầu bằng việc xác định có GitLab Self-Managed trong hạ tầng hay không và instance đó đang chạy phiên bản nào. Nếu thuộc phạm vi ảnh hưởng, khuyến nghị chính thức của GitLab là nâng cấp lên phiên bản đã khắc phục càng sớm càng tốt.

  •  Kiểm kê toàn bộ GitLab Self-Managed, bao gồm production, staging, development và instance cũ.

  •  Xác nhận chính xác phiên bản đang chạy trên từng hệ thống.

  •  Nâng cấp lên 18.11.11, 19.0.8, 19.1.6, 19.2.4 hoặc phiên bản mới hơn thuộc nhánh được hỗ trợ.

  •  Xác định GitLab hoặc GraphQL endpoint nào đang mở trực tiếp ra Internet.

  •  Kiểm tra lịch sử sửa, xóa public project và các thay đổi dữ liệu người dùng bất thường.

  •  Bảo toàn audit log, API log và reverse-proxy log phục vụ điều tra nếu cần.

  •  Kiểm tra backup của repository và dữ liệu quan trọng trước khi xảy ra tình huống cần phục hồi.

  •  Sau khi cập nhật, xác minh lại phiên bản và trạng thái hệ thống thay vì chỉ dựa vào thông báo update thành công.

Với tổ chức có nhiều máy chủ, website, API và dịch vụ public-facing, vấn đề thường không nằm ở việc “biết có CVE” mà là không biết tài sản nào trong doanh nghiệp đang chạy phiên bản dễ bị tấn công.

👉 Bài kiểm tra đánh giá an toàn thông tin cho doanh nghiệp của IPSIP trình bày cách rà soát phiên bản phần mềm, máy chủ, cổng dịch vụ, tài khoản, cấu hình và khả năng giám sát theo phạm vi hệ thống thực tế.

Góc nhìn chuyên gia từ IPSIP Việt Nam cho thấy điều gì?

GitLab chưa công khai đầy đủ chi tiết kỹ thuật hoặc điều kiện khai thác. Vì vậy, hiện chỉ có thể xác nhận điểm yếu nằm trong quá trình xử lý một GraphQL directive và được GitLab phân loại là Code Injection; chưa có đủ dữ liệu để kết luận sâu hơn về lỗi logic nội bộ.

Doanh nghiệp cũng nên tập trung audit log và reverse-proxy log về hệ thống giám sát trung tâm, duy trì backup có kiểm thử phục hồi, đồng thời giới hạn các giao diện quản trị hoặc API không cần thiết phải truy cập công khai từ Internet.

Với doanh nghiệp Việt Nam đang vận hành GitLab Self-Managed, ưu tiên hiện tại là kiểm tra phiên bản và triển khai bản vá của GitLab. Sau đó, cần rà soát log và những thay đổi bất thường trước thời điểm cập nhật. Về dài hạn, Asset Inventory, Patch Management, Vulnerability Management, backup và giám sát tập trung là các lớp kiểm soát giúp doanh nghiệp phản ứng nhanh hơn trước những bản vá Critical tương tự.

Nguồn tham khảo

Bình luận

theo dõi ipsip việt nam trên google news.png
conact-ipsip-vietnam
zalo
đặt lịch hẹn
bottom of page