Exposed GitLab email addresses let attackers push code

Some developers are publishing private GitLab email addresses in READMEs, contributing guides and support pages to collect bug reports. According to researchers at application security company Aikido, these addresses carry a credential that attackers can use to act on GitLab as the developer who owns them.

The addresses come from a built-in GitLab feature called "Email work item to this project." GitLab generates them automatically. When someone sends a message to one of these addresses, GitLab turns the email into an issue or task in the project.

The problem is that each address contains a long-lived token tied to the developer's account. This string works as the credential for creating work items by email.

A token hidden in the address

Every private address of this type includes a "glimt-" string that grants access to the project. The same string is used in all similar addresses generated for that project.

Aikido found that the address is not limited to issues. "Change the -issue suffix in the email address to -merge-request, and GitLab will open a merge request," the researchers said.

GitLab also does not check who sent the message. "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 explained. "Any mailbox on the internet can send to that address, and GitLab processes the message as the token's owner."

Aikido's tests also showed that the technique gets around IP address restrictions.

What an attacker can do depends on the permissions of the account behind the token. According to Aikido, a compromised account could be used to:

• push code to protected branches of private repositories
• steal source code
• collect secrets stored in CI/CD variables
• read confidential issues

The account's permissions cannot be bypassed. An attacker also needs the target project's path and ID. For public projects, both are easy to find. For private projects, the ID can be brute-forced, but the path would have to be leaked.

Addresses published on purpose

In a single afternoon, Aikido found a dozen live GitLab incoming email addresses in public documentation. The researchers say maintainers added them deliberately, so users could send bug reports.

Several of these addresses belonged to popular open-source projects. "A few belonged to very popular open source projects," the researchers noted. For projects with large user bases, this creates a supply-chain risk.

GitLab's own documentation says the addresses are private and "generated just for you." It warns: "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's response

Aikido reported the issue to GitLab through HackerOne, a bug bounty platform, in May. GitLab closed the report as "intended behavior."

Aikido sent a second notification in June. After that, GitLab made several changes:

• its UI now mentions merge requests
• it removed false statements about what data the token can access
• its documentation now says that incoming email bypasses IP restrictions

The researchers advise maintainers to stop publishing these addresses in public documentation. Anyone who has done so in the past should reset the tokens for the affected projects.

Our Take

This case is less about a classic software bug and more about a convenience feature whose risks were easy to miss. GitLab warned users to keep the addresses private, but maintainers still published them, apparently treating them as ordinary support inboxes. The fact that the same address could also open merge requests was not clearly documented until Aikido raised it a second time.

It fits a wider pattern in which public developer documentation becomes an entry point for attacks. Secrets stored in CI/CD pipelines are valuable to attackers, as shown by earlier cases such as the TeamCity flaw abused by ransomware gangs. A token that grants that kind of access through an email address deserves the same care as an API key.

For readers who maintain projects on GitLab, the practical step is to search READMEs, contributing guides and support pages for incoming email addresses and reset any exposed tokens. It is worth watching whether GitLab follows through on checking the sender's address. Aikido says the company is considering this, and it would close the most obvious gap. Until then, the safest assumption is that any published address of this kind has already been found.