GitLab Email Feature Exposes Accounts to Unauthorized Code Execution Risks

GitLab’s “email to issue” feature, designed to simplify project management, contains a security flaw that could allow unauthorised code execution. Researchers at Aikido Security have found that the feature uses a long-lived personal access token (PAT) embedded within project-specific email addresses, creating risks that extend across entire accounts.

While the email addresses are intended to be project-scoped, the underlying token is identical for every project within a single GitLab account. If a project email address is leaked or published in a public repository, any individual with the address can potentially act as the account owner.

Account-wide Access and CI/CD Risks

The vulnerability allows more than just simple issue creation. By altering the suffix of the embedded token, an attacker can trick GitLab into opening merge requests. This provides a pathway to submit crafted patches that could execute malicious code within a project’s continuous integration and continuous deployment (CI/CD) pipeline.

The embedded token also circumvents IP restrictions. Researchers demonstrated that while GitLab might block unauthorised browser access or git clone requests based on IP, the system still accepts the email and processes the resulting commit.

The specific vulnerable addresses follow a format containing a token prefixed by “glimt-“, such as: incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com.

GitLab Response and Mitigation

GitLab has stated that this behaviour is intended and not a vulnerability. However, following the disclosure by Aikido Security, the company updated its user interface description to explicitly state that the token can be used to create both issues and merge requests.

The severity of the risk is directly tied to the permissions of the linked account. If an account has the authority to push code to main branches or run CI/CD jobs, the embedded token inherits those exact rights.

To mitigate these risks, organisations should treat these email addresses as highly sensitive credentials rather than ordinary email endpoints. Security teams should scan public documentation and repositories for any exposed addresses. If an exposure is suspected, the email token should be reset immediately to invalidate the existing address.