Application security company Aikido revealed that email addresses for GitLab’s Email work item to this project feature sometimes appear in README files, contribution guides, and public support pages. These addresses contain a long-lived token linked to the developer’s account, making their publication more akin to exposing credentials than publishing an ordinary channel for receiving bug reports.
The feature allows anyone who sends a message to the address to create an issue or task in a GitLab project. However, tests conducted by Aikido showed that an attacker can change the -issue suffix in the address to -merge-request, causing GitLab to accept the message and create a merge request in the project.
What Could Happen in Practice?
The scope of the impact depends on the privileges of the account linked to the token. Potential outcomes may include introducing code changes, running CI/CD jobs, accessing private repositories, or extracting secrets stored in CI/CD variables, in addition to viewing confidential issues. In open-source projects, exposed addresses could become a supply-chain risk if they were used to introduce changes into projects relied upon by a large number of users.
During a single afternoon, Aikido researchers found approximately 12 active addresses published in public documentation, saying that some belonged to widely used open-source projects. An attacker does not need to spoof the token owner’s email address; GitLab processes the message as though it came from the token owner, and the tests also demonstrated that IP-address restrictions could be bypassed.
Exploitation Limitations and Administrators’ Responsibility
Exposing the address does not mean that the account’s privileges are bypassed; the user’s permissions remain a fundamental constraint. The attacker also needs to know the project’s path and identifier. This information is available in public projects, while targeting a private project requires the path to be leaked, even if the identifier could be brute-forced.
GitLab’s own documentation warns against sharing these addresses and describes them as private and generated for the relevant user, noting that anyone who knows them can create issues or merge requests as if they were the owner. The platform recommends resetting the token immediately if it is suspected of having been leaked.
What Does This Mean for Projects?
Aikido reported the issue to GitLab through HackerOne in May, but the report was closed as intended behavior. After a second notification in June, GitLab updated its interface to mention the ability to create merge requests, removed inaccurate statements about access to token data, and documented that receiving messages by email bypasses IP restrictions.
The most important practical step falls to project administrators: remove these addresses from public documentation and reset the tokens for projects where they were previously published. The open questions concern the extent to which GitLab may rely in the future on matching the sender’s address with the token owner’s email as an additional layer of defense, a mechanism that Aikido said the platform is currently considering.