GitLab’s Privileged Email Addresses Leave Organizations Vulnerable to Supply Chain Attacks
A recent study by Aikido Security has shed light on a critical vulnerability in GitLab’s platform, where incoming email addresses automatically assigned to each user contain highly privileged access tokens. These tokens grant broad user rights to an organization’s public and private projects, making it possible for attackers to launch supply chain attacks without needing actual access to the account.
The issue arises from the way GitLab handles email communication with its users. When a user emails their incoming address, a new issue is created in one of their authorized projects. What’s concerning is that these addresses contain non-expiring tokens that provide unfettered access to an organization’s resources – not just the project where the user is working. If an attacker obtains this email address and it’s publicly exposed, they can exploit it for malicious purposes.
Aikido’s research team discovered that GitLab users are often unaware of the risks associated with these addresses. In fact, a significant number of them have been intentionally exposed on the public internet. This lack of awareness is compounded by the fact that while the capabilities of these email addresses are documented, the risks are understated in GitLab’s user interface.
According to Joe Leon, an Aikido researcher, what started as a simple feature for creating project issues has evolved over time to include more functionality – such as sending merge requests and patch files – with privileged access. While this expansion was intended to enhance collaboration, it has inadvertently created a backdoor that attackers can exploit. “It wasn’t communicated clearly that there’s something sensitive in there that not only can create issues but push code,” Leon notes.
The tokens embedded in these email addresses are known as glimt- (GitLab Incoming Mail Token) prefixes, which are the same for all public and private projects to which a user has access. This means that if an attacker gains access to one of these addresses, they can modify the project path slug and ID to reach other private projects. Furthermore, Leon discovered that he could bypass IP address restrictions using GitLab email addresses, allowing him to push code to his private projects without actual access.
The implications of this vulnerability are far-reaching and potentially catastrophic for organizations relying on GitLab’s platform. The ease with which these tokens can be exploited makes it imperative for users to take immediate action to mitigate the risks associated with their incoming email addresses. By being aware of this vulnerability, users can take proactive steps to protect themselves from potential supply chain attacks.
To minimize the risk, organizations should review their internal policies and procedures regarding GitLab’s email addresses. Users should ensure that their email addresses are not publicly exposed and implement robust access controls to limit the privileges associated with these tokens. Furthermore, regular audits of project permissions and access controls can help identify potential vulnerabilities before they’re exploited by attackers. By taking a proactive approach to addressing this vulnerability, organizations can safeguard themselves against the devastating consequences of supply chain attacks.
Source: Dark Reading — 2026-09-23