# GitLab Email Address Flaw Exposes Users to Unauthorized Code Pushes

*Published September 25, 2026*
*Source: [https://thehackernews.com/2026/09/a-leaked-gitlab-issue-email-address.html](https://thehackernews.com/2026/09/a-leaked-gitlab-issue-email-address.html)*

## Executive Summary

*This is a Premium edition. The Executive Summary is available to sec-news.ai members —*
*[read it here](https://www.sec-news.ai/news/gitlab-email-address-flaw-exposes-users-to-unauthorized-code-pushes) or [see plans](https://www.sec-news.ai/pricing).*

## Article

GitLab users are facing a significant security vulnerability due to how the platform handles issue email addresses. Aikido Security has uncovered that the private email addresses GitLab assigns for filing issues can be exploited. If an attacker gains access to one of these email addresses, they can send patches that GitLab automatically commits under the victim's name. This vulnerability also allows attackers to trigger continuous integration and continuous deployment (CI/CD) jobs as if they were the legitimate user. The email address in question is displayed to users behind a button labeled 'Email work item to this project.' The core of this issue lies in the token embedded within the email address, which is tied to the user's account and does not expire. Aikido Security found that the same token applies across all projects a user can access, regardless of whether they are public or private. 

GitLab does not verify the sender of emails to these addresses, allowing any email account to exploit the vulnerability without needing access to the victim's mailbox. This flaw not only enables unauthorized code commits but also bypasses several security measures such as IP restrictions and two-factor authentication. While the impact of this vulnerability depends on the role of the compromised account, with higher roles like Maintainer allowing access to more sensitive areas, the risk remains significant for all users. 

Though GitLab has acknowledged the issue, the system behavior has not changed. The platform has updated the text description around the token to better inform users, but the token's non-expiry and lack of sender verification remain. GitLab is considering a change to accept emails only from verified addresses, but this solution is not yet implemented. Aikido Security initially reported the issue in May 2026 through HackerOne, where it was dismissed as intended behavior. The issue was subsequently brought to GitLab's attention in June. Users are advised to take preventative measures, though they cannot disable the feature independently.
