GitLab Email Token Lets Attackers Push Code to Main and Execute CI/CD Jobs

A long-lived GitLab incoming email token embedded in project email addresses for the “Email work item” feature can be exploited to push attacker-controlled code, create merge requests, and trigger CI/CD pipelines using the permissions of the token owner.

This issue can also bypass GitLab’s IP restrictions, as incoming email is explicitly excluded from those controls.

Security researcher Joe Leon from Aikido Security reported that GitLab’s private email addresses, which are intended to allow users to create issues by email, contain a credential that functions more like an account-wide, fine-grained access token than a project-scoped mail address.

The token does not expire and is reused across all projects accessible to the account, including private repositories.

GitLab Email Token Flaw

GitLab exposes a private email address through the “Email work item to this project” option. The address typically follows this format:

`incoming+project-id-glimt-<token>[email protected]`

While the interface historically described the address as a means to create project work items, the embedded glimt-incoming email token authenticates requests as the account owner.

GitLab’s documentation confirms that this incoming email token does not expire and that anyone who obtains it can create issues and merge requests as the associated user.

Aikido found that the token portion remains identical when a user retrieves project email addresses from multiple repositories. This means a token leaked from a public project’s README, support page, documentation, or issue template could potentially be used against other projects accessible to the same account.

The reported attack chain relies on GitLab’s merge-request-by-email workflow. An attacker who knows the target email address can modify the `-issue` suffix to `-merge-request`, submit a specially crafted email, and attach a Git patch file.

The email’s subject can specify a target source branch. GitLab will apply the supplied patch to that branch or create the branch if it does not already exist, using the victim’s permissions. If the compromised account has permission to push to protected branches, the attacker may be able to make commits directly to the main branch.

The risk increases significantly if the patch modifies the `.gitlab-ci.yml` file. If the victim’s role and pipeline settings allow it, GitLab can execute an attacker-defined CI/CD job in the target project.

This job might be utilized to access repository contents, retrieve CI/CD variables, extract secrets, or leverage the CI_JOB_TOKEN for additional access within the GitLab environment.

Aikido tested this behavior against a private project configured with an IP allowlist that excluded their address. GitLab blocked browser access and denied Git clone attempts; however, it accepted the merge request email, allowing the resulting commit to land on the main branch.

GitLab’s documentation now states that users can create issues and merge requests via email because incoming email does not fall under IP restrictions. Therefore, organizations should not consider GitLab IP allowlists as a comprehensive solution for repository modification workflows.

The attack does have limitations. The email token inherits the affected user’s existing permissions so that a low-privilege account would have less impact than a Maintainer or Owner account.

Additionally, attackers must know the intended project’s routing details, including its project path and ID. While these details are easy to obtain for public projects, private ones may require additional information leaks.

Organizations should treat GitLab incoming email addresses as sensitive information, not regular contact addresses.

• Immediately reset incoming email tokens if an address has been exposed, published, or suspected to have leaked. GitLab allows token resets under user profile settings and personal access tokens; resetting invalidates the associated incoming email addresses.
• Search through source repositories, documentation, wiki pages, issue templates, and public websites for glimt tokens and GitLab incoming email address patterns.
• Review users with Maintainer, Owner, and protected-branch push permissions, as their leaked tokens could lead to significant exposure.
• Audit CI/CD configurations for overly broad secret access, unrestricted pipelines, and excessive CI_JOB_TOKEN permissions.
• Treat IP allowlists as a layered control and not as sufficient protection against incoming email workflows.
• Monitor GitLab audit events, merge requests, branch creation, pipeline execution, and changes to `.gitlab-ci.yml` for unusual email-originated activity.

GitLab has updated its user interface and documentation following this disclosure to clarify that incoming email addresses can create both issues and merge requests.

GitLab also removed language suggesting the token could not access other data. However, the underlying mechanism remains unchanged, and GitLab’s documentation still states that the token does not expire and must be kept confidential.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC