Most people treat their GitLab email address like a convenience, a handy way to file a bug without opening a browser, and almost nobody treats it like a password, which is exactly the problem, because that address is a credential, and it never expires.

Here's the setup, GitLab gives every user a private email address for filing issues, you find it behind a button labeled "Email work item to this project," and when you send mail to it, GitLab opens an issue in that project with your name on it, as if you had logged in and typed it yourself.

Now here's the part that should make you uncomfortable, the string in the middle of that address is a token tied to your account, and GitLab's own documentation says it does not expire, so it does not rotate, it does not time out, and it does not care whether you still work at the company that issued it.

Aikido Security dug into this, and what they found is worse than a stale credential, because the addresses GitLab generates for your different projects all share the same token, and that token works on every project your account can open, public or private, so an address that looks like it belongs to one repo actually opens the door to all of them.

And GitLab does not check who sent the email, any mailbox can write to that address, and GitLab will act on the message as if it came from you, which means whoever holds the address can act with your permissions, without ever touching your inbox, your password, or your phone.

Quick Summary

Filing Bugs Is the Least of It

If the address only filed issues, this would be a mild annoyance, but Aikido showed it does much more, because GitLab has a merge request by email feature, and the address suffix is all that separates the two.

Change the suffix from -issue to -merge-request, and GitLab opens a merge request instead of an issue, then write a patch, put the target branch name in the subject line, attach the patch, and send it, and GitLab applies that patch to the branch, creating the branch if it does not exist yet.

The commit lands under your name, and if it is a branch you can push to, that includes main, so the attacker's code is now in your repository, wearing your identity, and if the patch edits .gitlab-ci.yml and your role permits it, GitLab runs the attacker's pipeline job as you.

The merge request cannot be pointed at a copy of the project the attacker controls, which is why the attached patch, not the merge request, is what carries the payload.

What Keeps This From Being Catastrophic

Two things blunt the impact, and both are worth understanding, because they decide how much a leaked address actually costs you.

First, the token carries only your own permissions, so a Guest account's leaked address is nearly worthless, while a Maintainer's address can reach protected branches and CI/CD secrets, which means the same bug is trivial for one user and severe for another.

Second, hitting a specific project takes more than the address, because GitLab figures out the target from the project's path and its numeric ID, and public projects publish both, while private projects need a separate leak that names them, though GitLab's project IDs are easy to guess once you know roughly where to look.

The Two Bypasses That Matter Most

This is where the flaw stops being a curiosity and starts being a real problem.

Incoming email is exempt from IP restrictions, and GitLab's documentation says so plainly, which means an attacker outside your corporate network can use the address even when your browser and your git client are locked out, and Aikido proved this by locking a private project to a single IP that was not theirs, GitLab blocked their browser and refused their clone, but it accepted the merge request email, and the commit landed on main.

The same path skips two-factor authentication, because GitLab's documentation notes that incoming email features work without 2FA, even on instances that require it, so a stolen address defeats the exact control most teams rely on to stop account takeover.

Who Is Actually Exposed

Every GitLab.com account has one of these tokens, and so does every self-managed instance with incoming email turned on, which is the default on GitLab.com, so the exposure is not niche, it is the default state of the platform.

GitLab Dedicated appears unaffected, since GitLab limits the feature to self-managed and GitLab.com, though Aikido said it could not test Dedicated directly, so treat that as unconfirmed rather than settled.

What You Can Do About It

You cannot stop other people from having the feature, but you can cut off a leaked address, and that is worth doing today.

Reset your incoming email token from the personal access tokens page in your profile, and remember that the reset replaces every project address at once, so any address you are actively using will stop working until you hand out the new one.

Then go looking for posted addresses, in your READMEs, your contributing guides, your support pages, and your old forum posts, because Aikido found about a dozen live addresses this way, most published on purpose as a place to send bug reports, and a few sitting in widely used open-source projects where anyone could pick them up.

If you run a self-managed instance, an administrator can turn incoming email off for the whole instance, but there is no per-user switch, so an individual cannot opt out while the feature stays on.

GitLab did update the wording around the token after Aikido's report, the description now says the address can create issues and merge requests, where it previously mentioned only work items, and GitLab removed a line claiming the token could not be used to access any other data.

The Behavior Itself Has Not Changed

The wording changed, the behavior did not, because the token still never expires, GitLab still does not verify the sender, and there is still no switch for an individual user to turn the feature off.

GitLab has opened an issue to consider accepting these emails only from an address verified on the account owner, but that is under discussion, not deployed.

Aikido said it first reported the behavior through HackerOne in May 2026, where it was closed as intended behavior, and then filed a confidential issue with GitLab in June, and GitLab's position, as Aikido describes it, is that this is a token like any other, and that any leaked credential leads to bad outcomes.

The Hacker News has reached out to GitLab and Aikido for comment.

The Bottom Line

GitLab's incoming email address is a credential that never expires, and it skips IP allowlists and 2FA, so anyone who holds it can commit code as you, to any branch you can push to, and can run CI/CD jobs as you, so if you have ever posted that address in a README or a support page, reset the token now, then go check your repositories for commits you did not author.

Quick Reference

What to Do

• Reset your incoming email token
• Search your READMEs and docs for posted addresses
• Ask your admin to disable the feature if you self-host
• Watch for commits you did not author
• Track GitLab's issue on sender verification

FAQ Section

What is the GitLab incoming email token vulnerability?

GitLab gives every user a private email address for filing issues, and the string inside that address is a token tied to the account, which never expires, so anyone who obtains the address can act as that user.

What can an attacker do with the address?

They can open issues as you, and they can also swap the suffix to -merge-request and email a patch that GitLab applies to any branch you can push to, including main, and they can trigger CI/CD jobs that run as you.

Do 2FA or IP allowlists stop this?

No, because GitLab documents that incoming email is exempt from IP restrictions, and that incoming email features work without 2FA, even on instances that require it.

Which instances are affected?

Every GitLab.com account, and every self-managed instance with incoming email turned on, while GitLab Dedicated appears unaffected but was not directly tested.

What should I do?

Reset your incoming email token, search your READMEs and docs for posted addresses, ask your admin to disable incoming email if you self-host, and watch for commits you did not author.

Source: The Hacker News