Understanding the Exposure of GitLab Project Email Addresses
Private GitLab email addresses used for issue and task management are being deliberately exposed in public documentation, READMEs, contributing guides, and support pages. These addresses are part of a built-in GitLab feature called 'Email work item to this project' and contain a long-lived token tied to the developer’s account. Researchers at Aikido have identified multiple private GitLab addresses exposed in public documentation, warning about the associated risks. These addresses are generated automatically and contain a string that serves as a credential for creating work items via email. When an external client sends a message to one of these addresses, GitLab parses it into a project issue or task.
The Impact of Exposed GitLab Email Addresses
An attacker could use these addresses to compromise GitLab accounts in attacks that push code to protected branches of private repositories, steal source code, collect secrets from CI/CD variables, or access confidential issues. Each of these private GitLab addresses embeds a 'glimt-' string that acts as a credential for accessing the project, persisting across all similar addresses generated for the respective project. GitLab's security documentation warns of the private nature of these addresses and advises users to keep them confidential.
Defending Against the Attack
In principle, checking the sending address matches the token owner's email could add a layer of defense, but GitLab does not currently implement this. The researchers also noted that an attacker could bypass IP address restrictions. The resulting level of access depends on the user’s account permissions and may allow code changes, CI/CD runs, access to private repositories, secrets, and more. GitLab advises users to reset the token immediately if they suspect a private email address was leaked.
Additional Security Measures
GitLab warns that these addresses are private and generated just for you. Project maintainers should stop voluntarily exposing this information in public documentation and reset tokens for projects they exposed this way in the past. Adaptive Security's AI agents can analyze email intent, context, and behavior to uncover phishing, business email compromise, and invoice fraud. See what's getting through with a 14-day read-only scan of Microsoft 365 or Google Workspace, with no MX changes.
Conclusion
Exposing GitLab project email addresses in public documentation is a significant security risk. Project maintainers should take immediate action to secure these addresses and follow GitLab's recommendations. Additionally, users should consider using adaptive security solutions like Adaptive Security's AI agents to enhance their defenses against email-based threats. By following these steps, organizations can mitigate the risks associated with exposed GitLab project email addresses and protect their systems and data from potential attacks.