GitLab incoming email addresses can push code, researchers say

On 23 September 2026 Aikido Security published research titled "Send GitLab an email, push to main". It describes a design and documentation problem rather than a classic bug. Aikido says a private "Email work item to this project" address embeds a long lived token, and anyone who holds the address can act as the account owner. No CVE is mentioned in the post.

What happened

Aikido (Joe Leon) describes this chain:

1. The victim's issue by email address is exposed, for example in a public README, wiki or support page.
2. The attacker changes the suffix from -issue to -merge-request.
3. The attacker emails a git .patch file with the target branch in the subject line. GitLab pushes to that branch or creates it.
4. If the patch adds a job to .gitlab-ci.yml and the owner's role permits it, GitLab runs the job as the owner.

Aikido says this works against projects with an IP allowlist, and that the token can reach CI/CD variables, confidential issues and the CI_JOB_TOKEN. The token inherits the owner's role, so a Guest address is much less dangerous than a Maintainer address. The attacker also needs the project path slug and ID, which are published for public projects. GitLab does not check the sender address.

Confirmed, reported and unknown

Reported by Aikido: the mechanism and the disclosure timeline. It says it reported through HackerOne in May 2026 and GitLab closed it as intended behavior. After a confidential issue in June, GitLab described the token as a token like any other that becomes dangerous once leaked. GitLab's changes, per Aikido, were UI text and documentation, including a note that incoming email is not subject to IP restrictions. Aikido says the underlying mechanism did not change and that there is no sender verification.

Not stated: affected and fixed versions (Aikido says GitLab.com and self managed instances with incoming email enabled are affected), whether anyone exploited this in the wild, and how many addresses are exposed. I did not fetch a GitLab statement of its own.

What to do now

1. Search your repositories, wikis and docs for your incoming email domain, and for addresses with a token before -issue or -merge-request.
2. If you find any, reset the incoming email token under User settings, then Personal access tokens. Aikido says this invalidates all of that user's project addresses.
3. Review recent commits, especially changes to .gitlab-ci.yml, and pipeline runs you do not recognize.
4. Rotate CI/CD variables if a leaked address belonged to a Maintainer or Owner.
5. On self managed instances, check whether the incoming email feature is needed and disable it if not.

How this could have been avoided

• Never publish a private email address, in a README, ticket template or support page. Treat it as a credential.
• Run secrets scanning across docs and wikis, not only code, with a rule for your incoming mail domain.
• Use protected branches that block pushes by anyone but a reviewed merge, so an emailed patch cannot land on main directly.
• Limit CI/CD variables to protected branches and tags, so a job on a new branch cannot read them.
• Prefer accounts with the lowest role that does the job, since the token inherits the role.

Try it yourself

Scan a folder of docs for secret shaped strings with the secrets scanning demo.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Aikido: Send GitLab an email, push to main