GitLab Issue Email Is a Push-to-Main Token

GitLab's Issue-By-Email Address Is a Push-to-Main Credential

Somewhere in your GitLab profile there is a button labelled "Email work item to this project". Click it and GitLab hands you a private address it formats exactly like an email address, because it is one. Mail anything to it and an issue appears in that project, authored by you. It reads like a convenience feature.

Research published by Aikido Security on September 23, 2026 shows that the address is a credential wearing an email's clothing — and a surprisingly powerful one. The token in the middle of the address is tied to your account, never expires, reaches every project you can open, and lets whoever holds it push code and run CI/CD jobs in your name.

The email address that is not scoped to the project

GitLab shows the same button in every project, and every project gives you a different-looking address. But the interesting part is identical across all of them:

incoming+<project-id>-glimt-<token>[email protected]

The glimt- string is a long-lived token bound to your account, not to that project or that mailbox. GitLab's own documentation says it does not expire. Open the button in five different projects — public or private — and the embedded token is the same one, and it authenticates you for any project your account can reach.

The UI sells the address as something narrower. Until Aikido contacted GitLab, the settings page stated the token "cannot be used to access any other data." Aikido describes it more like a fine-grained personal access token: scoped across all your groups and projects, carrying permissions such as Merge Request Create, Repository Update and Protected Branch Update.

And GitLab does not verify who sent the email. Any mailbox on the internet can write to the address, and GitLab processes the message as if it came from you. Holding the address is holding both the authentication and the authorization. You never need to touch the victim's actual inbox.

From filing bugs to pushing main

Aikido showed how the token turns into a code-push primitive using GitLab's own merge request by email feature:

1. Change the address suffix from -issue to -merge-request. GitLab now opens a merge request instead of an issue.
2. Write a git .patch and put the target branch name in the email subject line.
3. Attach the patch and hit send.
4. GitLab applies the patch to that branch — creating it if it does not exist — and the change lands as a commit authored by you.
5. If the patch touches .gitlab-ci.yml and your role allows it, GitLab runs the attacker's CI/CD job as you.

To:   [email protected]
Subject: main
Attachment: gitlab-ci-patch.diff

There is no fork involved; the merge request cannot be pointed at a copy the attacker controls. That is why the payload travels in the attached patch, not in the merge request itself. Anyone who builds from that repository from then on pulls in the attacker's code.

Aikido confirmed the full set of outcomes against projects it controlled: pushing code to a protected branch in a private repository behind an IP allowlist, exfiltrating source code from those same private projects, reading CI/CD variables and secrets, reaching confidential issues, and using the CI_JOB_TOKEN exposed in jobs to pivot further into the account.

The bypasses that make it worse

Two security controls people assume are load-bearing do not apply to the mail path.

Incoming email is exempt from IP restrictions. GitLab's documentation is explicit about it, and Aikido verified it live: it locked a private project to a single IP address that was not its own. The browser was blocked, git clone was refused — and the merge request email sailed straight through, landing a commit on main. Teams that draw a boundary around a project with VPN-edge IP allowlists have been guarding the HTTP and SSH doors while the mail slot stays wide open.

Incoming email works without 2FA. GitLab's administration docs state users can use incoming email features without authenticating with two-factor authentication first, even on instances that require 2FA. A leaked address therefore sidesteps the control that protects interactive sessions.

What actually limits the damage

Two constraints stop this from being a total account takeover:

• The token carries only your permissions. Nothing in the mail path escalates them. A leaked address for a Guest account is nearly useless; one for a Maintainer can reach protected branches and CI/CD secrets. Your role decides how far it goes.
• Routing needs the project path and numeric ID. GitLab resolves the destination from the project's path and ID embedded in the address, so reaching a specific project also needs those values. Public projects publish both; private ones need a separate leak (project IDs are guessable).

Neither is a comfort. Addresses are already circulating: Aikido spent one afternoon searching public docs and surfaced about a dozen live addresses in READMEs, contributing guides and support pages — most of them published on purpose by maintainers telling users where to send bug reports, a few in widely used open-source projects. GitLab also has no mechanism to bulk-revoke these tokens or notify affected users.

GitLab's response

Aikido first reported the behavior through HackerOne in May 2026, where it was closed as intended behavior, then filed a confidential issue in June. GitLab responded by merging merge request 247431: it removed the "cannot be used to access any other data" line, added "and merge requests" to the UI text, and documented that incoming email bypasses IP restrictions.

What did not change: the token still never expires, GitLab still does not verify senders, and there is no per-user switch to turn email-based issue or merge request creation off. GitLab has opened work item 617883 to consider accepting these emails only from an address verified against the account owner — that is under consideration, not shipped. GitLab's position, as Aikido relays it, is that this is a token like any other and any leaked credential leads to bad outcomes. A fair summary, with one uncomfortable addition: GitLab built a credential that reaches every project in the account and bypasses IP restrictions, then presented it as a copy-paste email address.

What you should do

1. Rotate your incoming email token now. The reset link lives on your personal access tokens page. It invalidates every project address at once — which also means any address you actively use stops working until you hand out the new one.
2. Scan for leaked addresses. Look through your READMEs, contributing guides and support pages for glimt- addresses. Aikido's open-source scanner Betterleaks now detects all GitLab incoming email token variants — glimt- prefixed, custom prefixes, and tokens minted before the prefix existed.
3. Stop treating GitLab IP allowlists as a security boundary. They block HTTP and SSH, not inbound email.
4. Self-managed instance? An administrator can disable incoming email instance-wide. Individual users have no off switch — if you run the instance, flip it off unless you genuinely use the feature.

This is a reminder in the same family as the Plugin4Shell git-pin bypass: supply-chain security dies in the gaps of convention. We treat email addresses as identifiers made to be shared, tokens as credentials, SSH as the only door, and main as protected. This finding quietly breaks all four assumptions at once. Rotate the token, then go grep your docs for that glimt- string — it is a very short search with a very long appendage.

Sources

• Aikido Security: Send GitLab an email, push to main
• The Hacker News: A Leaked GitLab Issue Email Address Lets Anyone Push Code and Run CI Jobs as You
• GitLab: GitLab incoming email documentation
• GitLab: Merge requests by sending an email
• GitLab: GitLab work item 617883 — verify incoming email sender
• GitLab: GitLab merge request 247431 — align incoming email token capability across UI and docs