A convenience feature built into GitLab — the ability to create or update an issue or merge request by sending an email — can be turned into a full repository-compromise tool if its private address ever leaks, according to research from Aikido Security published on September 23. The underlying problem is not a traditional software bug but a design choice: the incoming-email address embeds a long-lived authentication token that GitLab’s own documentation says never expires and must be kept secret.

Researcher Joe Leon found that while each project appears to get its own unique incoming address, the token portion is actually tied to the account, not the individual project. That means once an attacker obtains a single one of these addresses tied to a user, they effectively hold a credential that grants them the ability to act as that person across every project they can reach.

From Issue Spam to Code Execution

The most alarming part of the finding is how far the abuse can extend beyond simple issue creation. Aikido’s researchers discovered that swapping the “-issue” suffix in a leaked address for “-merge-request,” attaching a Git patch to the email, and naming a source branch in the subject line is enough to make GitLab apply that patch directly to the specified branch — or create the branch outright — using the permissions of whoever owns the token.

Because the action executes with the victim’s own permissions, the potential impact scales with that person’s role. A patch that modifies a project’s .gitlab-ci.yml pipeline configuration can trigger attacker-controlled code inside the CI/CD environment, potentially exposing source code, pipeline secrets, and job tokens. If the compromised account belongs to a Maintainer, the technique can reportedly reach protected branches such as main, with the resulting commits appearing to have been made by the legitimate account owner.

Bypassing Network Restrictions

Perhaps the most consequential detail in the research is what it reveals about GitLab’s IP-restriction feature. Aikido configured a private test project to accept connections only from a specific, unrelated IP address. As expected, both browser access and Git cloning were blocked for any other source. The emailed patch, however, went through anyway and landed a commit on the main branch — because GitLab’s email-processing pipeline is not subject to the same IP allowlist rules that protect the web and Git interfaces.

GitLab has since updated its documentation to explicitly state this exception, but the underlying behavior remains unchanged: organizations relying on IP allowlisting as a security boundary for a project should not assume it covers the email work-item channel.

No Sender Verification Required

Exploiting the flaw does not require spoofing a specific sender address, since GitLab currently does not require that incoming mail originate from an address verified on the token owner’s account — only that it be sent to the correct destination address with a valid token embedded in it. GitLab has opened an internal issue to explore adding that verification step, but it has not shipped yet.

An attacker still needs two pieces of information to pull off the attack: the private email address itself, and enough context about the target project — its path and project ID — to route the patch correctly. For public repositories that information is trivially available; targeting a private project would generally require the address to leak through some other channel first, such as a support ticket, internal documentation, or a misconfigured integration.

GitLab’s Response and Recommended Defenses

GitLab has classified the reported behavior as functioning as designed rather than a conventional security vulnerability, though it merged documentation and interface changes clarifying exactly what the token can do and urging users to treat it as sensitive. The email-to-issue and email-to-merge-request mechanisms themselves remain active.

Security teams should treat this as an action item rather than background reading. Recommended steps include:

• Search repositories, wikis, tickets, support logs, and any public-facing documentation for exposed glimt- style incoming-mail addresses.
• Reset the incoming email token for any account where exposure is suspected, which invalidates the associated project addresses immediately.
• Audit affected users’ permissions, protected-branch rules, CI/CD variables, and recent commit and audit-log history for signs of abuse.
• Treat every generated project email address as a full account credential rather than a harmless contact address going forward.