Security1 publisher2 min readPublished
A GitLab issue-email address lets any mailbox commit to main as its owner
All of a user's GitLab issue-by-email addresses carry the same account token, and Aikido Security showed that any mailbox holding one can land a commit on any branch that user can push to, main included.
The Watch · Security desk
What happened
- Aikido Security found that all of the issue-by-email addresses GitLab creates for one user share a single token, and that the token works on every project that account can open, public or private.
- Swapping the address suffix from -issue to -merge-request and naming a branch in the subject line makes GitLab apply an attached patch to that branch as a commit authored by the address owner.
- The string in the middle of the address is a token tied to the account, and GitLab's documentation says it does not expire.
- GitLab does not check who sent the mail, so any mailbox can write to the address and GitLab acts on the message as though the account holder sent it.
- Aikido locked a private project to a single IP address that was not its own, and GitLab blocked its browser and refused a git clone but accepted the merge request email, landing the commit on main.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure The reach of a leaked address is set by the role of the person it belongs to: a Guest's is close to worthless, a Maintainer's opens protected branches and CI/CD secrets.
- constraint An IP allowlist does not fence this path, so network controls stop being the thing that keeps writes out of a locked-down private project.
- decision Rotation is the only lever an individual user holds, and it kills every one of that user's project addresses at once, so any team advertising one for bug reports has to reissue it or lose the inbox.
The address alone will not reach an arbitrary project. GitLab works out the target from the project's path and its numeric ID, so an attacker who wants a specific repository needs both of those as well as the token [8]. Public projects publish both. A private one takes a separate leak that names it, though GitLab's project IDs are easy to guess [8].
GitLab will not let the email aim the merge request at a copy of the project the attacker controls, so the code sits in the attached patch [6]. GitLab applies that patch to the branch named in the subject line, creates the branch if it does not exist, and commits it under the account holder's name [4]. If the patch edits the project's .gitlab-ci.yml and the account's role allows it, GitLab runs that job as the account holder [5].
Every GitLab.com account has one of these tokens, and so does every user of a self-managed instance with incoming email switched on, which is the default on GitLab.com [12]. GitLab Dedicated appears to sit outside it, because GitLab limits the feature to self-managed and GitLab.com, but Aikido said it could not test Dedicated directly [13].
GitLab's documentation notes that incoming email features work without 2FA, even on instances that require it [11]. The button that hands a user the address is labeled "Email work item to this project", and mail sent to it opens an issue in that project authored by that user [18].
The reset sits on the personal access tokens page in the user's profile, and it replaces every project address at once, so an address in active use stops working until the new one is handed out [14]. Aikido said it found about a dozen live addresses by reading READMEs, contributing guides and support pages, most of them posted on purpose as a place to send bug reports, and a few in widely used open-source projects [15]. On a self-managed instance an administrator can turn incoming email off for the whole instance; there is no setting that lets an individual user turn off email-based issue or merge request creation [16].
After Aikido's report, GitLab changed the text around the token. The description now says the address can create issues and merge requests, where before it listed only work items [17].
What to watch
- Whether GitLab adds sender verification, a token expiry, or a per-user off switch for incoming email, or leaves the fix at documentation.
- Whether GitLab Dedicated is confirmed unaffected by an actual test rather than by the feature's stated scope.
- Whether the addresses Aikido found posted in public repos get rotated, or stay live as bug-report inboxes.