GitLab’s Project Email Feature Exposes Account Credentials, Enabling Unauthorized Code Commits and CI/CD Execution

Security researchers have uncovered a significant security implication involving GitLab’s built-in feature for filing issues via email. According to findings published by cloud security firm Aikido Security, the private email addresses generated by GitLab for handling incoming project issues function effectively as permanent, high-privilege credentials. If compromised, an unauthorized individual can exploit these addresses to commit code directly in a victim’s name, target protected branches such as the main branch, and trigger automated Continuous Integration and Continuous Deployment (CI/CD) pipelines operating under the user’s permissions.

The mechanism at the core of this behavior is integrated directly into the standard user experience on GitLab. When navigating a project, users can locate a button labeled "Email work item to this project," which reveals a unique email address assigned to that specific context. Messages sent to this address are designed to automatically open an issue within the designated project, with the system attributing authorship to the account owner.

However, a deeper analysis conducted by Aikido Security revealed that the alphanumeric string embedded in the middle of these email addresses is a persistent token tied directly to the user account rather than an isolated project. Furthermore, GitLab’s current documentation indicates that this token does not possess an expiration date.

The security implications broaden significantly when examining the scope of these tokens. While the addresses appear tailored to individual projects, researchers discovered that the addresses generated for a user’s various projects actually share the exact same underlying token. This means that a single leaked email address can be leveraged against every public or private project that the compromised user account has permission to access.

Compounding the risk is the absence of sender verification. GitLab does not validate the true origin mailbox of incoming messages sent to these addresses. Instead, the platform processes incoming emails and acts upon them as if they originated directly from the legitimate account owner. Consequently, anyone who acquires the email address can impersonate the user and execute actions matching their exact permission level, all without ever gaining direct access to the victim’s actual email inbox.

Beyond simply filing bug reports or creating standard work items, Aikido Security demonstrated how malicious actors can repurpose these addresses to push arbitrary code into repositories. By leveraging GitLab’s native feature that allows users to create merge requests by sending emails, attackers can attach malicious patches to communications routed through the system. While the merge request itself cannot be directed toward an external repository controlled by an attacker, the attached patch carries the payload directly into the target environment.

The potential damage of such an exploit is directly tied to the privilege level of the compromised user account. Because the underlying token inherits only the permissions of its owner, the severity of a leak varies considerably. For instance, a leaked email address belonging to a user with a Guest role remains largely inconsequential due to restricted access. Conversely, if an address belonging to a Maintainer or Owner account is exposed, an attacker gains the ability to interact with protected branches and access sensitive CI/CD variables and secrets stored within the project.

Executing an attack requires more than just the token string alone; successful targeting also necessitates the project’s unique path and its numeric ID. While public projects readily publish this information, targeting a private project would typically require a separate information leak to discover its specific path and identifier. Nevertheless, GitLab’s project IDs are often considered easy to enumerate or guess by determined actors.

The attack vector also bypasses standard organizational perimeters and authentication controls. According to GitLab’s official documentation, incoming email processing is expressly exempt from IP restriction policies. Aikido Security tested this behavior by locking a private project down to a single, external IP address. While GitLab subsequently blocked browser access and refused standard Git clone operations from unauthorized locations, it successfully accepted the merge request email, allowing the unauthorized commit to land directly on the main branch.

Similarly, this operational pathway circumvents multi-factor authentication (MFA). GitLab documentation notes that incoming email integrations continue to function smoothly even on instances or accounts where two-factor authentication is strictly enforced.

Every standard user account on GitLab.com features one of these persistent tokens by default. The capability is also active across self-hosted, self-managed GitLab instances where the incoming email feature is enabled, which remains the default setting on the main platform. Meanwhile, GitLab Dedicated instances do not appear to be affected in the same manner, largely because the platform limits the incoming email feature, though researchers were unable to directly test Dedicated environments.

While individual users cannot completely disable the feature globally across the platform, they can take steps to mitigate risks associated with a potentially leaked address. GitLab updated its platform terminology following Aikido Security’s disclosure. The updated interface descriptions now explicitly state that these email addresses can be used to create both issues and merge requests, whereas previous documentation referred only to work items and explicitly stated that the tokens could not be utilized to access other data structures.

Despite these textual clarifications, the underlying mechanics remain unchanged. The tokens continue to lack an expiration mechanism, the platform still does not verify sender authenticity, and there is currently no individual user toggle available to deactivate the feature entirely. GitLab has since opened an internal tracking issue to evaluate potential improvements, such as restricting incoming emails exclusively to addresses verified by the account owner, though this modification remains under consideration rather than deployed.

The disclosure timeline reveals that Aikido Security initially reported the behavior through the HackerOne bug bounty platform in May 2026, where it was initially closed as intended platform behavior. Subsequently, the researchers filed a confidential issue directly with GitLab in June. GitLab’s stance throughout the disclosure process has maintained that the string functions as a standard credential token, noting that any leaked credential of any type inherently introduces security risks to an environment. Representatives for both GitLab and Aikido Security have been approached for further comment regarding ongoing mitigation strategies.