GitLab’s Email Exposure
In a recent revelation, GitLab users face a potential security issue due to the exposure of a private email address used for filing issues by email. This vulnerability, identified by Aikido Security, allows unauthorized individuals to submit patches and initiate CI/CD jobs on behalf of the user without proper authentication. This significant flaw could lead to unauthorized code being committed to branches, including the main branch, without the user’s direct involvement.
How the Vulnerability Occurs
GitLab assigns each user a unique email address for project-related communications, visible through a button labeled “Email work item to this project.” However, the email address contains a token linked to the user’s account, which GitLab does not expire. Aikido Security discovered that this token is consistent across different projects within a user’s account, allowing it to be used across various projects, whether public or private.
The critical issue is that GitLab does not verify the sender’s email, leading to a scenario where any attacker with the email address can act with the user’s permissions. By altering the email’s suffix from “-issue” to “-merge-request,” an attacker can create merge requests, thereby committing code and initiating CI/CD processes.
Extent and Limitations of the Issue
While this vulnerability presents significant risks, its impact depends on the permissions associated with the user’s role. For example, a leaked address with Guest permissions poses minimal threat, whereas a Maintainer-level access could allow changes to protected branches and access to CI/CD secrets. Additionally, attackers need both the project’s path and numeric ID to target specific projects successfully, which public projects readily display.
Another layer of complexity is added by the fact that incoming emails are not restricted by IP addresses, allowing attackers to bypass IP allowlists. Furthermore, GitLab’s system does not enforce two-factor authentication for actions initiated via email, even if the instance requires it for regular logins.
Steps for Mitigation
Users concerned about this vulnerability can take several actions to mitigate the risk. Resetting the incoming email token from the personal access tokens page can invalidate all existing addresses, although this requires redistributing new addresses. Users should also inspect public documentation, such as READMEs or support pages, for any inadvertently exposed email addresses.
For administrators of self-managed GitLab instances, disabling the incoming email feature entirely is an option, although this affects all users on the instance. Despite these precautions, the underlying behavior of the token remains unchanged, and GitLab is considering measures to accept emails only from verified addresses.
GitLab’s current stance, as reported by Aikido, views the token as a standard credential where any exposure can lead to negative outcomes. The issue, first reported through HackerOne in May 2026, remains a topic of discussion as GitLab evaluates potential security improvements.
