Token email của GitLab cho phép đẩy code và chạy CI mà không cần xác thực

Các nhà nghiên cứu bảo mật tại Aikido Security đã phát hiện ra một lỗ hổng nghiêm trọng trong tính năng nhận email đến (incoming email) của GitLab, cho phép kẻ tấn công đẩy code và thực thi các job CI/CD chỉ bằng một địa chỉ email bị rò rỉ. Được báo cáo vào giữa năm 2026, lỗi này ảnh hưởng đến cả GitLab.com và các instance tự quản lý (self-managed) nơi tính năng nhận email được bật, về cơ bản coi token email tĩnh như một thông tin đăng nhập có đặc quyền cao, giúp qua mặt các biện pháp kiểm soát bảo mật tiêu chuẩn như xác thực hai yếu tố và danh sách IP cho phép.

Chuyện gì đã xảy ra

Cốt lõi của vấn đề nằm ở cách GitLab xử lý việc chuyển đổi từ email sang work item. Mỗi tài khoản người dùng trên GitLab đều được gán một token duy nhất, không hết hạn, được nhúng trong địa chỉ email dùng để tạo issue. Mặc dù địa chỉ này trông có vẻ cụ thể cho từng dự án, nhưng Aikido Security phát hiện ra rằng token nền tảng được chia sẻ trên tất cả các dự án mà người dùng đó có quyền truy cập. Do đó, bất kỳ ai lấy được địa chỉ email này đều có thể tương tác với bất kỳ dự án công khai hoặc riêng tư nào mà người dùng có quyền truy cập, bất kể dự án nào ban đầu hiển thị địa chỉ đó.

Lỗ hổng leo thang vượt ra ngoài việc đơn thuần là tạo issue. Bằng cách thay đổi hậu tố địa chỉ email từ -issue thành -merge-request, kẻ tấn công có thể gửi trực tiếp các bản vá (patch) vào repository. Nếu kẻ tấn công biết đường dẫn và ID số của dự án mục tiêu, họ có thể gửi một email kèm theo bản vá code. GitLab sẽ xử lý email này như một merge request, áp dụng bản vá vào nhánh được chỉ định. Nếu người dùng có quyền đẩy code vào nhánh đó, bao gồm cả các nhánh được bảo vệ như main, code sẽ được commit dưới danh tính của người dùng. Hơn nữa, nếu bản vá sửa đổi tệp .gitlab-ci.yml, GitLab sẽ thực thi các job CI/CD kết quả với quyền của người dùng, có khả năng làm lộ các bí mật (secrets) hoặc gây tổn hại cho hạ tầng.

Chi tiết chính

• Token chia sẻ: Token email giống nhau đối với tất cả các dự án mà người dùng có thể truy cập, nghĩa là một vụ rò rỉ từ một dự án sẽ làm mất an toàn quyền truy cập vào tất cả các dự án khác.
• Không xác minh người gửi: GitLab không xác minh địa chỉ email của người gửi so với chủ sở hữu tài khoản, cho phép bất kỳ hộp thư nào hành động thay mặt người dùng.
• Vượt qua các biện pháp kiểm soát bảo mật: Các hành động qua email đến được miễn trừ khỏi các hạn chế IP và yêu cầu xác thực hai yếu tố, ngay cả khi chúng được áp dụng ở những nơi khác.
• Phụ thuộc vào đặc quyền: Tác động tăng lên theo vai trò của người dùng; tài khoản Guest có tác động hạn chế, trong khi Maintainer có thể đẩy code vào các nhánh được bảo vệ và truy cập secrets của CI.
• Xác định mục tiêu: Kẻ tấn công cần đường dẫn dự án và ID số bên cạnh token, mặc dù ID dễ đoán và đường dẫn thường là công khai.
• Không thể tắt ở cấp độ người dùng: Người dùng cá nhân không thể tắt việc tạo issue hoặc merge request qua email; chỉ quản trị viên instance mới có thể vô hiệu hóa tính năng này trên toàn hệ thống.

Bối cảnh

Tính năng nhận email đến của GitLab được thiết kế để tối ưu hóa quy trình làm việc bằng cách cho phép người dùng tạo issue hoặc merge request thông qua các ứng dụng email. Điều này đặc biệt hữu ích cho các nhóm quản lý phân loại (triage) qua giao diện email hoặc muốn giảm rào cản cho những người đóng góp bên ngoài khi báo cáo lỗi. Hệ thống dựa vào một địa chỉ email độc nhất cho mỗi kết hợp người dùng-dự án, chứa một token ẩn dùng để xác thực hành động.

Tuy nhiên, các token xác thực thường yêu cầu chính sách bảo mật và xoay vòng (rotation) nghiêm ngặt. Trong trường hợp này, token là tĩnh và không bao giờ hết hạn. Mặc dù GitLab coi đây là một thông tin đăng nhập tiêu chuẩn, nhưng việc tích hợp nó với hệ thống email tạo ra một điểm mù. Các biện pháp bảo mật truyền thống như whitelisting IP, vốn giới hạn quyền truy cập vào các mạng đã biết, không áp dụng cho lưu lượng email đến. Tương tự, xác thực hai yếu tố (2FA), vốn thêm một lớp xác minh thứ hai cho các lần đăng nhập, bị bỏ qua vì hệ thống email tin tưởng token một cách ngầm định mà không thách thức người gửi.

Tại sao điều này quan trọng

Đối với các đội ngũ vận hành instance GitLab tự host hoặc sử dụng GitLab.com, lỗ hổng này nhấn mạnh một khoảng trống nghiêm trọng trong bảo mật chuỗi cung ứng. Các nhà phát triển thường chia sẻ thông tin liên hệ trong các tệp README, hướng dẫn đóng góp hoặc trang hỗ trợ để thuận tiện cho việc báo cáo lỗi. Nếu các tài liệu này chứa địa chỉ email đặc biệt của GitLab, họ vô tình công bố một thông tin đăng nhập cấp quyền ghi code. Aikido Security đã tìm thấy khoảng một tá địa chỉ đang hoạt động được công khai rộng rãi, bao gồm trong các dự án mã nguồn mở phổ biến.

Khả năng vượt qua các hạn chế IP đặc biệt đáng lo ngại đối với các doanh nghiệp phụ thuộc vào bảo mật cấp độ mạng để bảo vệ codebase của họ. Một kẻ tấn công bên ngoài mạng nội bộ vẫn có thể đẩy code độc hại vào nhánh chính nếu họ sở hữu token email. Điều này phá vỡ giả định rằng các nhánh chỉ dành cho nội bộ là an toàn trước các mối đe dọa từ bên ngoài. Ngoài ra, việc thực thi các job CI/CD dưới tư cách người dùng bị xâm phạm có thể dẫn đến sự di chuyển ngang (lateral movement) sâu hơn trong hạ tầng, đặc biệt nếu các job đó có quyền truy cập vào khóa triển khai (deployment keys) hoặc thông tin đăng nhập đám mây.

Bạn có thể làm gì

• Đặt lại token: Đi tới trang personal access tokens của bạn trong GitLab và đặt lại token email đến của bạn. Thao tác này sẽ vô hiệu hóa ngay lập tức tất cả các địa chỉ dự án hiện có.
• Kiểm toán tài liệu công khai: Tìm kiếm trong các tệp README, hướng dẫn đóng góp và trang hỗ trợ của dự án xem có bất kỳ địa chỉ email GitLab nào được đăng tải hay không và xóa chúng.
• Vô hiệu hóa email đến: Nếu bạn là quản trị viên của một instance tự quản lý, hãy cân nhắc tắt tính năng nhận email đến trên toàn hệ thống nếu nó không thiết yếu cho quy trình làm việc của bạn.
• Giám sát merge request: Theo dõi chặt chẽ các merge request được tạo qua email, đặc biệt là những cái nhắm vào các nhánh được bảo vệ hoặc sửa đổi các tệp cấu hình CI.
• Nâng cao nhận thức cho thành viên nhóm: Thông báo cho các nhà phát triển rằng địa chỉ email hiển thị trên nút "Email work item" là một thông tin đăng nhập nhạy cảm, chứ không chỉ là một phương thức liên lạc.
• Kiểm tra rò rỉ: Sử dụng các công cụ hoặc tìm kiếm thủ công để xem liệu các địa chỉ email GitLab của tổ chức bạn có được đăng trên các diễn đàn công khai hoặc kho lưu trữ code hay không.