GitLab Email Feature Flaw Allows Code Injection into Private Repositories
A vulnerability in GitLab's email work item feature allows attackers to push code into private repositories by exploiting exposed project email addresses.
Researchers have uncovered a significant vulnerability within GitLab's "Email work item to this project" feature, which, when a project's private email address is exposed, can be weaponized by attackers to inject malicious code directly into private repositories. The core of the issue lies in a long-lived, non-expiring token embedded within these project-specific email addresses, which GitLab documentation confirms grants the holder the ability to create issues and merge requests.
While the feature is intended for creating work items via email, Aikido Security researcher Joe Leon discovered that the email address mechanism is broader than initially apparent. Attackers can manipulate the email's structure, replacing the standard "-issue" suffix with "-merge-request," and then attach a Git patch. By specifying a source branch in the email subject, an attacker can effectively force GitLab to apply this patch to the designated branch using the permissions of the token owner.
This capability opens the door to serious security breaches. A malicious patch targeting the project's CI/CD configuration file (.gitlab-ci.yml) could lead to the execution of attacker-controlled code. Depending on the compromised user's role and the project's pipeline setup, this could result in the exposure of sensitive source code, CI/CD variables, job tokens, or other critical secrets. Furthermore, if the compromised token belongs to a user with Maintainer privileges, attackers might even be able to commit directly to protected branches, such as 'main,' with their actions appearing to originate from the legitimate user.
The vulnerability also bypasses certain network security assumptions. Aikido's research demonstrated that even when a private project was configured to restrict access to specific IP addresses, GitLab still accepted emailed patches, allowing a malicious commit to land on the main branch. This highlights that GitLab's incoming email functionality is not subject to the same IP restrictions as browser or Git cloning access, rendering IP allowlists insufficient as a complete defense for these workflows.
Exploiting this flaw requires two main components: knowledge of the private project email address and sufficient routing information to identify the target project, including its path and project ID. While public repositories readily expose this information, attacking private projects would typically necessitate an additional information leak to obtain these details. Notably, the exploitation does not require sender email verification, as GitLab does not currently enforce this for incoming emails associated with the token.
GitLab has acknowledged the behavior, stating it was designed rather than a conventional vulnerability, but has implemented changes to clarify the token's capabilities. The interface and documentation have been updated to explicitly mention both issue and merge request creation, emphasize the need for token secrecy and reset procedures, and detail the exception to IP restrictions. However, the underlying email mechanism remains functional.
To mitigate this risk, organizations are advised to actively search their repositories, documentation, logs, and public pages for exposed "glimt-" email addresses or older custom incoming email tokens. If an exposure is suspected, the incoming email token should be reset via personal access token settings, which will invalidate all associated project email addresses. Additionally, a thorough review of affected users' permissions, protected branch rules, pipelines, variables, commits, and audit events is recommended. GitLab now treats every project email address as a sensitive credential, akin to an account password.
This new report reveals that the leaked private issue email addresses can also be leveraged to push code and execute CI/CD jobs. By altering the email suffix from '-issue' to '-merge-request' and specifying a target branch in the subject, an attacker can submit patches that are committed in the victim's name, even to the main branch. Furthermore, if the patch modifies the project's .gitlab-ci.yml file, the attacker can trigger automated workflows to run as the compromised user.