GitLab Incoming-Email Tokens Expose Users to Code Pushes and CI Execution as the Account Owner

Aikido Security found that GitLab's auto-assigned incoming-email addresses embed a non-expiring account-wide glimt- token that lets anyone holding it commit patches, open merge requests, and trigger CI/CD as the owner, bypassing IP allowlists and 2FA; GitLab…

Aikido Security researcher Joe Leon reported that GitLab's "Email work item to this project" feature assigns every GitLab.com account an incoming-email address embedding a long-lived glimt- token that does not expire and authenticates as the account owner across every project the account can access. Anyone who obtains the address can email a Git patch that GitLab commits with the owner's permissions — including to main or, with a Maintainer role, to protected branches — and can change .gitlab-ci.yml so attacker-controlled CI/CD jobs run, potentially exposing source code, variables, secrets, or CI_JOB_TOKEN. Changing the address suffix from issue to merge-request opens merge requests as the owner, and GitLab does not verify the sender. Incoming email bypasses IP allowlist restrictions that block browser and git access as well as two-factor authentication. Exploitation still requires the secret address plus project routing details (path and numeric ID), and impact depends on the user's role. Aikido found roughly a dozen live addresses already published in public documentation such as READMEs, contributing guides, and support pages, including one for the wget2 project. GitLab initially closed Aikido's May HackerOne report as intended behavior, then updated its interface warning text (now mentioning merge requests as well as issues), documentation, and token-reset guidance; verified-sender checks are only being considered, and the non-expiring token remains. No CVE has been assigned and no in-the-wild exploitation has been reported across any of the sources.

• GitLab auto-assigns each user an incoming-email address for the "Email work item" feature, embedding a long-lived glimt- token that does not expire.
• The token is account-wide, works across every project the account can access, and authenticates actions as the owner.
• Holders can create issues, open merge requests by changing the address suffix, and have emailed Git patches committed with the owner's permissions, including to main; a Maintainer-level token may commit to protected branches.
• A modified .gitlab-ci.yml can run attacker-controlled CI/CD jobs that may expose source, variables, secrets, or CI_JOB_TOKEN.
• Incoming email bypasses IP allowlist restrictions and two-factor authentication, and GitLab does not check the sender address.
• Exploitation requires the secret address plus project routing details (project path and numeric ID); impact depends on the user's role.
• Aikido found about a dozen exposed addresses in public documentation, including one for the wget2 project.
• GitLab treated the behavior as intended, closed Aikido's May HackerOne report on that basis, then updated its interface warnings and documentation and provided token-reset guidance; verified-sender checks are only under consideration.