GitLab private email addresses exposed, risk of unauthorised merge requests

Many teams that host code on GitLab share private email addresses in public documentation such as READMEs, contribution guides and support pages. Those addresses contain a long‑lived token that is linked to a developer’s account and can be used to create issues or merge requests by email. When the address is visible to anyone, an attacker can modify the address and open a merge request with the token owner’s permissions, bypassing IP‑based restrictions.

What is being exposed?

GitLab automatically generates a private email address for each user that enables the Email work item to this project feature. The address follows the pattern [email protected] and embeds a token that never expires unless the user resets it. Project maintainers sometimes paste this address in public documentation to make it easy for external contributors to report bugs.

How the exploit works

1. An attacker discovers a published address, for example alice+my‑app‑[email protected].
2. By changing the suffix from ‑issue to ‑merge‑request, the address becomes alice+my‑app‑merge‑[email protected].
3. GitLab accepts the email, creates a merge request and attributes it to the token owner, Alice, without checking that the sending mailbox belongs to her.
4. Because the token is not tied to a specific IP, the request succeeds even if the project is configured to allow only certain IP ranges.

The vulnerability stems from the lack of verification that the sender’s email matches the token owner. As a result, any mailbox that knows the address can act with the token holder’s rights.

Photo by cottonbro studio on Pexels

Why it matters for your business

• Unauthorised code changes, An attacker can push malicious changes directly into a merge request, potentially introducing supply‑chain compromises.
• Privilege escalation, The merge request is created under the token owner’s identity, giving the attacker the same access rights as that user.
• Bypassing network controls, Projects that rely on IP whitelisting for protection lose that defence when the email token is abused.
• Long‑lived credentials, The token does not expire automatically, so exposure remains a risk until the token is manually reset.

GitLab’s response

The issue was first reported through GitLab’s HackerOne programme in May. GitLab initially marked the behaviour as intended, but after a follow‑up in June the company updated its user interface and documentation. The UI now warns that the email address can be used to open merge requests, removes the claim that the token grants data‑access rights, and advises users to reset exposed tokens.

What you should do now

1. Audit public documentation, Search your public repositories, wikis and support pages for any string that ends with ‑[email protected]. Remove any matches.
2. Reset affected tokens, For each exposed address, go to the user’s Profile → Settings → Incoming email token page and click Reset this token.
3. Disable the feature where not needed, If you do not require email‑based issue or merge‑request creation, disable the Email work item option in the project settings.
4. Add a warning banner, Update your internal documentation to note that the private email address must never be published.
5. Monitor audit logs, Review GitLab audit logs for any activity that originates from the affected token after reset. Look for events such as Create merge request or Push code that do not correspond to known user actions.
6. Restrict token scope, Where possible, use project‑scoped tokens with limited permissions instead of personal tokens.

Taking these steps removes the immediate exposure and reduces the chance of a similar issue re‑appearing.

Photo by Daniil Komov on Pexels

Terms used in this article

• Token, A secret string that authenticates a user or service without requiring a password.
• IP address restriction, A network control that allows access only from specified IP ranges.
• Merge request, A GitLab feature that proposes code changes to be integrated into a target branch.
• Audit log, A record of actions performed in the GitLab instance, useful for forensic analysis.

This article is based on independent reporting of the exposure and GitLab’s subsequent updates.