Cybersecurity Researchers Warn of Exposed GitLab Email Addresses That Let Attackers Push Code
A critical vulnerability in GitLab’s email work item feature has been exposed by application security company Aikido, leaving thousands of projects vulnerable to attacks. The issue lies in the auto-generated private email addresses that allow developers to push issues or tasks to a project via email. These addresses contain a long-lived token tied to the developer’s account and are being deliberately exposed in public documentation.
The email addresses are part of GitLab’s built-in feature, which allows external clients to send messages to these addresses, which are then parsed into project issues or tasks by GitLab. Researchers at Aikido found multiple private GitLab addresses exposed in READMEs, contributing guides, and support pages used for collecting bug reports. These exposures affect not only open-source projects but also popular ones with large user bases.
An attacker could use these exposed email addresses to compromise GitLab accounts and gain access to protected branches of private repositories, steal source code, collect secrets from CI/CD variables, or access confidential issues. The researchers tested the vulnerability and found that an attacker can change the ‘-issue’ suffix in the email address to ‘-merge-request’, allowing them to open a merge request on the project.
GitLab’s current implementation does not verify whether the sending address matches the token owner’s email, making it possible for any mailbox on the internet to send messages to these addresses and have GitLab process them as if they were from the token owner. This allows attackers to bypass IP address restrictions and gain access to sensitive areas of a project.
The researchers note that while permission restrictions cannot be bypassed, an attacker needs only the target project’s path and ID to exploit this vulnerability. In public projects, this information is publicly available, but in private projects, the ID can be brute-forced, although the path would need to be leaked.
Aikido reported the issue to GitLab through HackerOne in May, but it was initially closed as “intended behavior.” After a second notification from Aikido in June, GitLab updated its UI and removed false statements about token data access. Project maintainers are advised to stop voluntarily exposing this information in public documentation and reset tokens for projects they exposed this way in the past.
This vulnerability serves as a reminder of the importance of maintaining project security, especially when using third-party tools like GitLab. It’s crucial for developers and maintainers to be aware of the potential risks associated with exposing sensitive information in public documentation and take steps to mitigate them.
Source: Bleeping Computer — 2026-09-24