Exposed GitLab Email Addresses Pose Serious Security Risk
Researchers at application security firm Aikido discovered multiple private GitLab email addresses accidentally exposed in public project documentation, including README files, contributing guides, and support pages. These addresses are part of GitLab’s built-in "Email work item to this project" feature, which generates unique email addresses containing long-lived tokens tied to individual developer accounts. When an external sender emails one of these addresses, GitLab automatically parses the message into a project issue or task, acting as if the message came from the token owner.
How Attackers Can Exploit These Exposed Addresses
The exposed email addresses contain a credential string identified by the ‘glimt-’ prefix, which persists across all similar addresses generated for a given project. Attackers who obtain these addresses can manipulate the suffix to change the type of work item created. For example, changing the ‘-issue’ suffix to ‘-merge-request’ causes GitLab to interpret the incoming email as a request to open a merge request, allowing unauthorized code changes.
"Change the -issue suffix in the email address to -merge-request, and GitLab will open a merge request," Aikido researchers stated.
Critically, GitLab does not verify that the sending email address matches the token owner’s email, meaning any mailbox on the internet can send to these addresses and have their messages processed as the legitimate user. Furthermore, Aikido’s testing confirmed that this attack bypasses IP address restrictions that might otherwise limit access to private repositories.
Impact Depends on User Permissions and Project Access
The level of access an attacker gains depends entirely on the permissions of the account associated with the exposed token. If the token belongs to a maintainer or administrator, the attacker could push code to protected branches, run CI/CD pipelines, access private repositories, extract secrets from CI/CD variables, and read confidential issues.
To exploit this vulnerability in a private project, an attacker needs both the project’s path and ID. While the path may require prior leakage, the project ID can be brute-forced in some cases. In public projects, both pieces of information are readily available, significantly increasing the risk of supply-chain attacks targeting widely used open-source software.
GitLab’s Response and Recommended Mitigations
GitLab’s own documentation warns users that these email addresses are private and should be treated like passwords: "Keep it to yourself, because anyone who knows it can create issues or merge requests as if they were you. If you suspect this private email address was leaked, reset the token immediately."
Aikido reported the issue to GitLab via HackerOne in May 2026, but the initial report was closed as "intended behavior." A follow-up in June 2026 prompted GitLab to update its user interface to clarify that the feature supports merge requests, correct misleading documentation about token data access, and explicitly note that incoming email bypasses IP restrictions.
Project maintainers are advised to immediately audit their public documentation for any exposed GitLab email addresses, remove them, and reset the associated tokens for any projects where exposure may have occurred in the past.
Source: BleepingComputer