GitLab Project Email Tokens Exposed in Public Docs Could Enable Code and Secret Theft
GitLab project email addresses that let developers create issues and tasks are being intentionally published in README files, contribution guides, and support pages used to collect bug reports.
These addresses are part of GitLab’s built-in “Email a work item to this project” feature. They contain long-lived tokens tied to a developer’s account and are intended to remain private.
When someone sends an email to one of these addresses, GitLab parses the message and creates an issue or task in the associated project. However, researchers at application security company Aikido warn that anyone who obtains a project email address may be able to abuse it.
Exposed GitLab email tokens can create merge requests
Attackers could potentially use exposed GitLab email addresses to compromise projects, push code to protected branches in private repositories, steal source code, access CI/CD variables, and view sensitive issues.
Each private GitLab email address contains an embedded “glimt-” string that acts as a credential for creating work items. According to Aikido, this string persists across similar addresses generated for the same project.
“If you change the -issue suffix in your email address to -merge-request, GitLab will open a merge request,” Aikido says.
Source: Aikido
An attacker who knows or obtains a project email address could change the -issue suffix to -merge-request. GitLab will then accept the message and open a merge request in the project.
“In principle, checking that the sending address matches the token holder’s email would add an additional layer of defense, but GitLab does not do this (they are considering it now),” the researchers said.
“Any mailbox on the internet can send to that address, and GitLab will process the message as the owner of the token.”
Aikido also found that the attack bypasses IP address restrictions.
Impact depends on GitLab account permissions
The resulting access level depends on the token owner’s account permissions. In some cases, this may allow an attacker to modify code, run CI/CD jobs, access private repositories and secrets, and perform other actions available to the account.
The researchers noted that attackers still need the target project’s path and ID, in addition to the private email address. A public project exposes this information, while the ID of a private project can be brute-forced. However, the project path must still be leaked.
GitLab’s documentation warns that these email addresses are private and “generated specifically for the user.”
“Keep this information private, because it allows us to create issues and merge requests as if it were you. If you suspect that this private email address has been compromised, please reset your token immediately,” GitLab warns.
GitLab project email addresses published in public documentation
One afternoon, Aikido researchers found 12 live GitLab project email addresses in public README files, contribution guides, and support pages.
The researchers said the addresses had been intentionally included in public documentation so users could send bug reports to project maintainers.
In several cases, the exposure affected popular open-source projects, creating potential supply-chain risks for their large user bases. “Some belonged to very popular open source projects,” the researchers said.
Aikido reported the issue to GitLab through HackerOne in May, but GitLab closed the report as “intended behavior.”
The company submitted a second notice in June, asking GitLab to update its user interface to mention merge requests, remove inaccurate statements about token data access, and document that incoming emails bypass IP restrictions.
How GitLab administrators can reduce the risk
Project administrators should avoid publishing private GitLab project email addresses in public documentation. They should also reset tokens for projects that have exposed these addresses in the past.
Join Mikko Hypponen and security leaders from the NFL, Chanel, and Atlassian for a 2-hour digital summit about what will change with AI speed attacks, what defenders should stop doing, and how to verify, decide, fix, and revalidate at machine speed.
Source: www.bleepingcomputer.com