Leaked GitLab email tokens can enable code pushes and CI jobs

Aikido Security has reported that GitLab’s incoming-email address for creating work items can function as a reusable account credential. Anyone who obtains the address can submit email that GitLab processes as the account owner, potentially committing code to branches the user may update and launching CI/CD jobs under that user’s permissions.

GitLab exposes the address through the “Email work item to this project” control. Although it appears project-specific, Aikido found that the token embedded in addresses generated for different projects is shared for the same user and applies to projects that account can access. GitLab documentation says the token does not expire.

From issue email to a branch commit

The reported technique relies on GitLab’s merge-request-by-email capability. An attacker can change the address suffix from -issue to -merge-request, put a target branch name in the email subject, and attach a patch. GitLab applies that patch to the selected branch, creating the branch when it does not exist, and records the commit as the token owner.

If the owner has permission to push to a branch, the target can include main. A patch that modifies .gitlab-ci.yml can also cause GitLab to execute a CI/CD job with the owner’s available permissions. Aikido noted that the merge request cannot be aimed at an attacker-controlled copy of the project, which is why the attached patch is the delivery mechanism.

Controls that incoming email can bypass

GitLab does not verify the sender of incoming email against the account owner. The address can therefore be used from any mailbox without access to the owner’s inbox. Incoming email is also exempt from IP restrictions, and GitLab documents that these features work without two-factor authentication, including where 2FA is required.

Aikido tested an IP-restricted private project and found that GitLab blocked browser access and a Git clone from an unapproved address, but accepted a merge-request email and applied the commit to main. The scope of an attack remains constrained by the compromised account’s role: a Guest account offers little value, while a Maintainer may have access to protected branches and CI/CD secrets.

Exposure depends on more than the token

To reach a specific project, an attacker also needs its path and numeric project ID, which GitLab uses to identify the destination. Both values are public for public projects. Private projects require a separate disclosure that identifies them, although Aikido noted that project IDs are easy to guess.

The issue affects GitLab.com accounts and self-managed instances where incoming email is enabled. GitLab Dedicated does not appear to be affected because the feature is limited to GitLab.com and self-managed deployments, although Aikido said it could not test Dedicated directly. GitLab has revised wording around the token to say it can create issues and merge requests, but Aikido said the underlying behavior has not changed.

Actions for development teams

Users can reset the incoming-email token from the personal access tokens page, replacing all of their project email addresses at once. Teams should search READMEs, contribution guides, and support pages for published addresses; Aikido found about a dozen live examples, including addresses intentionally listed for bug reports. Self-managed administrators can disable incoming email for the entire instance, while individual users have no setting to disable email-based issue or merge-request creation. The practical implication is to inventory these addresses as credentials, remove public exposure, and reset tokens promptly when a leak is suspected.