Exposed GitLab project email addresses let attackers push code

Private GitLab email addresses that allow developers to push issues or tasks to a project are being deliberately exposed in READMEs, contributing guides, and support pages used to collect bug reports.

The 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.

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 them, GitLab parses it into a project issue or task.

Researchers at application security company Aikido found multiple private GitLab addresses exposed in public documentation and are warning about the associated risk.

An attacker could use them 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 address embed a ‘glimt-’ string that acts as a credential for accessing the project, which persists across all similar addresses generated for the respective project.

“Change the -issue suffix in the email address to -merge-request, and GitLab will open a merge request,” Aikido says.

An attacker who knows that address or can retrieve it could change the ‘-issue’ suffix to ‘merge-request,’ and GitLab would accept it, opening a merge request on the project.

“In principle, checking the sending address matches the token owner’s email would add a layer of defense, but GitLab doesn’t do this (though they are now considering it),” the researchers say.

“Any mailbox on the internet can send to that address, and GitLab processes the message as the token’s owner.”

Additionally, Aikido’s tests showed that the attack would bypass IP address restrictions as well.

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, etc.

The researchers note that, besides the permission restriction, which cannot be bypassed, an attacker also needs the target project’s path and ID.

In public projects, this info is publicly available, while in private projects, the ID can be brute-forced, but the path would need to be leaked.

GitLab warns in its documentation about the security implications of exposing these addresses, saying that they are private and “generated just for you.”

“Keep it to yourself, because anyone who knows it can create issues or merge requests as if they were you. If you suspect this private email address was leaked, reset the token immediately,” GitLab warns.

Exposed private email addresses

In one afternoon, Aikido researchers found a dozen live GitLab incoming email addresses in public READMEs, contributing guides, and support pages.

The researchers say that these addresses were deliberately included in public documentation to send bug reports to maintainers.

In many cases, the exposure affected popular open-source projects, creating supply-chain risks for large user bases. “A few belonged to very popular open source projects,” the researchers say.

Aikido says it reported the issue to GitLab through HackerOne in May, but GitLab closed it as “intended behavior.”

The company followed up with a second notification in June, prompting GitLab to update its UI to mention merge requests, remove false statements about token data access, and document that incoming email bypasses IP restrictions.

Project maintainers should stop voluntarily exposing that info in public documentation and reset tokens for projects they exposed this way in the past.