GitLab's attempt to simplify issue creation through a dedicated email address has inadvertently exposed significant security vulnerabilities. The project-scoped email addresses, designed for developers to send messages and generate issues, come with a long-lived token embedded in the address itself. This flaw potentially allows anyone who knows this email address to modify repositories indiscriminately, especially if those addresses are unintentionally made public.
The security firm Aikido Security has highlighted alarming findings regarding this feature. Any user with the email can trigger actions not just in particular projects but across all repositories that the account can access. It's important to note that this feature is activated by default for all accounts on GitLab.com and also has the potential to be enabled on self-managed GitLab instances.
“Anyone holding that address can push code and run CI/CD jobs in every project your account can reach,” Aikido explained in their blog that detailed the risks. Joseph Leon, a security researcher at Aikido, pointed out, “The biggest challenge with the existing design is anyone with an email account can email to that address and act as that GitLab user.” His recommendation stresses the importance of requiring the ‘from’ email address to match that of the GitLab user to mitigate these threats effectively.
IP Restrictions Not Applicable
While GitLab supports IP address restrictions for account access, these measures do not extend to actions triggered via email. Aikido tested this functionality and noted, “GitLab blocked our browser and rejected git clone. It accepted the email, and the commit landed on main.” GitLab maintains that this situation does not constitute a vulnerability; however, Aikido raises concerns regarding the inherent design flaw where a credential capable of widespread access bypasses significant security measures.
The problematic email addresses typically follow the structure: incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com. The core issue lies in the personal access token (PAT) embedded in these addresses, which GitLab emphasizes should remain confidential. “Keep this token secret. Anyone who has it can create issues as if they were you,” is the warning issued by GitLab regarding the email token.
Aikido has challenged GitLab's claim that the token “cannot be used to access any other data.” They argue that different projects tied to the same account use an identical embedded token, thus opening a pathway to all public and private repositories associated with the account. The token's misuse extends beyond merely creating issues; altering its suffix could allow an assailant to initiate a merge request, thereby gaining the ability to execute malicious code changes within a project’s CI/CD pipeline.
Potential for Merge Requests
Following Aikido's findings, GitLab updated the user interface description to clarify that these tokens could enable the creation of both issues and merge requests. This enhancement doesn’t translate into unrestricted access; actions remain limited by the original user's account permissions.
“The organizational impact depends entirely on the user’s existing permissions,” Leon noted. If an attacker can push code to a main branch or run CI/CD jobs on a project, the risk associated with the email address gains substantial weight. Nonetheless, targeting other projects isn't straightforward; an attacker must provide both the path and ID of any intended target. While public project paths are readily accessible, private project paths might require leaks or educated guesses about their IDs.
Leon observed a concerning number of exposed email addresses within a short search, noting that some belonged to high-profile open-source projects like wget2. The findings suggest that the likelihood of exposure is considerably high, warranting immediate attention from project stakeholders.
Aikido proposes that these email addresses should be treated with the same caution afforded to sensitive credentials. Organizations are encouraged to actively monitor for exposed addresses within public documentation and repositories. In cases of suspected exposure, they've advised invalidating the prior email tokens to safeguard against unauthorized access.
This article first appeared on InfoWorld.
