Lỗ hổng bảo mật trên tính năng “Email work item to this project” của GitLab có thể bị khai thác để chiếm quyền kiểm soát kho lưu trữ (repository-compromise) khi địa chỉ email riêng tư của dự án bị lộ. Nghiên cứu được công bố bởi Joe Leon, nhà nghiên cứu tại Aikido Security vào ngày 23 tháng 9 năm 2026, đã chỉ ra rằng địa chỉ này chứa một token glimt-incoming-email tồn tại lâu dài và không hết hạn, do đó cần được giữ bí mật tuyệt đối.
Theo tài liệu của GitLab, bất kỳ ai sở hữu token này đều có thể tạo các issue và merge request dưới danh nghĩa chủ sở hữu token. Điều này mở rộng phạm vi nguy hiểm vượt xa việc gửi spam issue. Mặc dù giao diện hiển thị địa chỉ email riêng cho từng dự án, Aikido đã phát hiện ra rằng các địa chỉ được tạo cho các dự án khác nhau lại nhúng cùng một token cấp tài khoản.
Khai thác lỗ hổng bảo mật
Kẻ tấn công có thể thay thế hậu tố -issue bằng -merge-request, đính kèm một bản vá Git và xác định một nhánh nguồn (source branch) trong chủ đề email. Sau đó, GitLab sẽ áp dụng bản vá đó vào nhánh đã chỉ định hoặc tạo nhánh mới bằng quyền của nạn nhân. Đặc biệt, một bản vá độc hại có thể sửa đổi tệp .gitlab-ci.yml.
Việc sửa đổi tệp .gitlab-ci.yml có thể kích hoạt mã CI/CD do kẻ tấn công kiểm soát, dẫn đến các nguy cơ nghiêm trọng. Tùy thuộc vào vai trò của người dùng bị xâm phạm và cấu hình pipeline, điều này có thể dẫn đến việc lộ mã nguồn, các biến CI/CD, token job hoặc các thông tin nhạy cảm khác. Đây là một hình thức tấn công mạng nguy hiểm, làm tăng thêm các mối đe dọa cho doanh nghiệp.
Nếu địa chỉ email riêng tư của một người dùng có vai trò Maintainer bị lộ, kẻ tấn công thậm chí có thể thực hiện commit lên các nhánh được bảo vệ như main, với các hành động hiển thị dưới danh tính của nạn nhân. Ngược lại, một token có vai trò Guest sẽ bị giới hạn bởi quyền hạn của người dùng đó.
Vượt qua kiểm soát mạng
Nghiên cứu của Aikido Security cũng chỉ ra rằng cơ chế gửi email này làm suy yếu các giả định về kiểm soát mạng. Các nhà nghiên cứu đã cấu hình một dự án riêng tư chỉ chấp nhận địa chỉ IP không liên quan. GitLab đã chặn truy cập trình duyệt và clone Git, nhưng lại chấp nhận bản vá được gửi qua email, cho phép thực hiện commit lên nhánh main.
GitLab hiện đã ghi nhận rõ ràng rằng việc gửi email đến không bị giới hạn bởi địa chỉ IP, điều này có nghĩa là danh sách cho phép (allowlist) không còn là ranh giới bảo mật hoàn chỉnh cho các quy trình làm việc này. Điều này cho thấy tầm quan trọng của việc cập nhật bản vá và các biện pháp bảo mật bổ sung.
Yêu cầu để khai thác
Để khai thác lỗ hổng này, kẻ tấn công cần có địa chỉ email riêng tư của dự án cùng với đủ thông tin định tuyến để xác định dự án mục tiêu, bao gồm đường dẫn và ID của dự án. Các kho lưu trữ công khai thường tiết lộ những chi tiết này. Đối với các dự án riêng tư, các cuộc tấn công thường yêu cầu một vụ rò rỉ thông tin khác để thu thập các chi tiết cần thiết.
Việc giả mạo địa chỉ người gửi (sender spoofing) là không cần thiết bởi GitLab hiện không yêu cầu tin nhắn phải xuất phát từ một địa chỉ email đã được xác minh trong tài khoản của chủ sở hữu token. GitLab đã mở một issue để xem xét việc xác minh này trong tương lai.
Phản ứng của GitLab và biện pháp phòng ngừa
GitLab ban đầu xem hành vi này là thiết kế có chủ đích thay vì một lỗ hổng bảo mật theo quy ước. Tuy nhiên, họ đã tiến hành hợp nhất các thay đổi để làm rõ khả năng của token. Giao diện người dùng và văn bản tài liệu đã được cập nhật để đề cập đến cả issue và merge request, nhấn mạnh tầm quan trọng của việc giữ bí mật và quy trình đặt lại token, đồng thời giải thích về ngoại lệ kiểm soát IP. Tuy nhiên, cơ chế gửi email cơ bản vẫn còn tồn tại.
Các chuyên gia bảo mật khuyến nghị người dùng nên ngay lập tức tìm kiếm trong các kho lưu trữ, tài liệu, vé hỗ trợ, nhật ký (logs) và các trang công khai để phát hiện các địa chỉ glimt- và các định dạng token email đến cũ hoặc tùy chỉnh. Việc phát hiện sớm các dấu hiệu rủi ro bảo mật là vô cùng quan trọng.
Trong trường hợp nghi ngờ địa chỉ bị lộ, người dùng cần đặt lại token email đến trong phần cài đặt personal access-token, điều này sẽ vô hiệu hóa các địa chỉ dự án liên quan. Các tổ chức cũng nên xem xét lại quyền hạn của người dùng bị ảnh hưởng, các quy tắc về nhánh được bảo vệ, pipeline, biến số, commit và các sự kiện kiểm toán. Quan trọng nhất, mọi địa chỉ email của dự án nên được coi như một thông tin xác thực tài khoản, chứ không phải là một địa chỉ liên hệ thông thường.
