GitLab Email Feature Vulnerability Lets Attackers Push Code Into Private Repositories

GitLab’s “Email work item to this project” feature can become a repository-compromise primitive when its private address is exposed, according to research published by Aikido Security researcher Joe Leon on September 23, 2026.

The address contains a long-lived glimt- incoming-email token that GitLab says does not expire and must remain secret. GitLab documentation confirms that anyone possessing it can create issues and merge requests as the token owner.

The flaw extends far beyond issue spam. Although the interface presents a project-specific address, Aikido found that addresses generated for different projects embed the same account-level token.

An attacker can reportedly replace the -issue suffix with -merge-request, attach a Git patch, and identify a source branch in the email subject. GitLab then applies the patch to that branch or creates it using the victim’s permissions.

A malicious patch modifying .gitlab-ci.yml can consequently trigger attacker-controlled CI/CD code in the victim’s project. Depending on the compromised user’s role and pipeline configuration, this could expose source code, CI/CD variables, job tokens, or other secrets.

A Maintainer’s leaked address may even permit commits to protected branches, including main, while actions appear under the victim’s identity. A Guest token, by contrast, remains limited by that user’s permissions.

According to research published by Aikido Security, the mail route also undermines assumptions surrounding network controls. Aikido said its researchers configured a private project to accept only an unrelated IP address; GitLab blocked browser access and Git cloning but accepted the emailed patch, landing a commit on main.

GitLab now explicitly documents that incoming email is not subject to IP restrictions, meaning allowlists are not complete security boundaries for these workflows.

Exploitation requires the private address plus enough routing information to identify a target project, including its path and project ID. Public repositories disclose those details, while attacks against private projects would generally require another information leak.

Sender spoofing is unnecessary because GitLab does not currently require messages to originate from an email verified on the token owner’s account. GitLab has opened an issue to explore such verification.

GitLab treated the reported behavior as designed rather than a conventional vulnerability, but merged changes clarifying the token’s capabilities.

Updated interface and documentation text now mentions both issues and merge requests, emphasizes secrecy and reset procedures, and explains the IP-restriction exception. The underlying email mechanism, however, remains available.

Defenders should immediately search repositories, documentation, tickets, logs, and public pages for glimt- addresses and older or customized incoming-mail token formats.

Suspected exposure requires resetting the incoming email token under personal access-token settings, which invalidates associated project addresses.

Organizations should also review affected users’ permissions, protected-branch rules, pipelines, variables, commits, and audit events, while treating every project email address as an account credential, not a harmless contact address.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC