GitLab's Email-to-Issue Feature Leaks Account Tokens When Exposed in Public Docs

A built-in GitLab capability that converts incoming email into project issues and tasks is creating a security gap when the associated private addresses end up in public repositories. The feature, called "Email work item to this project," generates unique email addresses containing embedded tokens tied to developer accounts. When these addresses are shared in README files, contribution guidelines, or bug-reporting pages—often intentionally to streamline external submissions—they expose credentials that persist indefinitely.

Security researchers at Aikido discovered multiple instances of these private addresses exposed across public documentation and flagged the risks. An attacker with access to such an address could leverage it to push code into protected branches of private repositories, exfiltrate source code, retrieve secrets stored in CI/CD variables, or view confidential project issues.

How the Attack Works

Each private GitLab address contains a credential string beginning with 'glimt-' that grants access to the project. This token remains valid across all similar addresses generated for that project. The researchers demonstrated that modifying the email suffix from '-issue' to '-merge-request' causes GitLab to accept the message and open a merge request instead of creating an issue.

GitLab currently does not verify that the sending email address belongs to the token owner. According to Aikido, "Any mailbox on the internet can send to that address, and GitLab processes the message as the token's owner." The researchers also confirmed that IP address restrictions, which some organizations implement as a security measure, are bypassed entirely by this attack vector.

The scope of compromise depends on the compromised account's permissions within the project. Attackers could potentially modify code, trigger CI/CD pipelines, access private repositories, or retrieve stored secrets. However, Aikido notes that attackers still need to know the target project's path and ID. In public projects, this information is readily available, but private projects require either leaked path information or brute-forcing of the ID.

GitLab's own documentation warns users about these risks, stating that the addresses are private and "generated just for you." The company instructs users to keep the addresses confidential and to reset tokens immediately if exposure is suspected.

Widespread Exposure in Open Source

During a single afternoon of research, Aikido identified a dozen active GitLab incoming email addresses published in public READMEs, contribution guidelines, and support pages. The researchers determined that developers had deliberately included these addresses in public documentation to facilitate bug reporting from external contributors.

The exposure affected multiple high-profile open-source projects, introducing supply-chain risks for their user communities. "A few belonged to very popular open source projects," the researchers noted.

GitLab's Response

Aikido reported the vulnerability to GitLab through HackerOne in May, but the company initially closed the report as "intended behavior." A follow-up notification in June prompted GitLab to make several changes: updating the user interface to clarify merge request functionality, correcting documentation that contained inaccurate statements about token data access, and documenting that incoming email bypasses IP restrictions.

The researchers recommend that project maintainers remove these private email addresses from public documentation immediately and reset tokens for any projects where exposure has occurred.