GitLab’s Issue Email Functionality Exposes Projects to Security Risks

GitLab's feature, designed to simplify issue creation through project-specific email addresses, presents significant security concerns. Aikido Security discovered that these email addresses, which should facilitate communication, also provide an entry point for unauthorized users to alter protected repositories if the addresses are shared or disclosed.

The email address, accessible via a button labeled “Email work item to this project,” effectively grants full access to both private and public projects. Aikido’s analysis highlights that the feature is automatically enabled for all GitLab.com users, and there’s no option to disable it. Self-hosted GitLab instances may also have this feature active.

“Anyone in possession of that address can execute code and initiate CI/CD jobs across any project the user can access,” said Aikido in a blog post outlining their findings.

Joseph Leon, a security researcher at Aikido, emphasized a major flaw: “Anyone with an email account can use that address to act as if they’re the GitLab user.” He noted that requiring the sender’s email to match the user’s GitLab email could dramatically reduce these risks.

IP Restrictions Don't Apply

While GitLab permits users to impose IP address restrictions to bolster security, these measures do not extend to email communications. Aikido reported attempts to access their GitLab account from a blocked IP were thwarted, yet emails were accepted without restriction. “GitLab blocked our browser, but the email went through, allowing the commit to be pushed to the main branch,” they noted.

This function was designed this way deliberately, as clarified by GitLab, but Aikido disputes this characterization, arguing that it creates a significant security weakness by allowing a broad-reaching credential embedded within an email address.

The pertinent email format includes a personal access token (PAT) prefixed with “glimt-,” which GitLab aims to keep confidential. The platform warns users to keep this token private, stating that anyone with access can perform actions as if they were the legitimate user.

Aikido challenged GitLab’s claim that the token is harmless, asserting that while it’s stated that the token “cannot be used to access any other data,” this is inaccurate. The email addresses, unique to different projects under the same account, share identical tokens, allowing for potential exploitation across various repositories.

Aside from creating GitLab issues, this token can be used to instigate other actions, such as submitting a merge request, by merely altering the token suffix. If exploited, this could allow an attacker to introduce malicious code into a project’s CI/CD environment.

Risks in Merge Requests

Upon Aikido's revelation, GitLab updated its UI notifications to ensure users recognize that the token allows not only the creation of issues but also the initiation of merge requests.

While the potential for widespread damage exists, it's worth noting that the impact is contingent upon the permissions tied to the account. “The damage ranges widely based on the user's permissions,” Leon explained. “If a user can push code or execute CI/CD jobs, the risk is exacerbated.”

For private projects, targeting requires more effort since access paths must be identified; casual guessing may suffice for project IDs, but path information must be leaked.

Leon’s findings indicate that the likelihood of such email addresses being exposed is substantial, as he discovered multiple incidents of exposure online within a short period, including cases linked to well-known open-source projects.

Aikido recommends treating these project email addresses as sensitive credentials, advising organizations to proactively scan for their exposure in public repositories. If any address is found to be compromised, it’s wise to reset the email token to safeguard against unauthorized access.

This article first appeared on InfoWorld.