GitLab’s “Email work item to this project” feature can be abused as a repository-compromise mechanism if its private incoming-email address is exposed. The address contains a long-lived glimt- token that GitLab states does not expire and must be kept secret. Anyone possessing the token can create issues and merge requests with the permissions of the associated account. Researcher reported that addresses generated for different projects can contain the same account-level token, increasing the impact of an exposed address. The issue was reported on September 23, 2026, and GitLab treated the behavior as designed rather than as a conventional vulnerability.

The impact extends beyond creating unauthorized work items because the incoming-email mechanism can reportedly be used to submit Git patches. By modifying the -issue suffix to -merge-request, attaching a Git patch, and specifying a source branch in the email subject, an attacker can cause GitLab to apply the patch to an existing branch or create a new branch using the victim’s permissions. A malicious modification to .gitlab-ci.yml could then trigger attacker-controlled CI/CD code, potentially exposing source code, CI/CD variables, job tokens, and other secrets depending on the victim’s permissions and pipeline configuration. If the exposed token belongs to a Maintainer, the attacker may potentially commit to protected branches, including main, with actions appearing under the victim’s identity, while lower-privileged accounts remain constrained by their existing permissions.

The research also demonstrated that network restrictions may not fully protect this workflow. Researcher reported that a private project configured to allow access only from an unrelated IP address blocked browser access and Git cloning, but still accepted a patch submitted through the incoming-email mechanism and placed a commit on the main branch. GitLab has subsequently documented that incoming email is not subject to IP restrictions. Exploitation does not require sender spoofing because GitLab does not currently require the email to originate from a verified address belonging to the token owner. However, an attacker needs the private incoming-email address and sufficient routing information to identify the target project, such as its project path and ID; public repositories can expose these details, while attacks against private projects would generally require an additional information leak.

Organizations should treat GitLab project incoming-email addresses as credentials rather than ordinary contact information and immediately search repositories, documentation, tickets, logs, and public pages for exposed glimt- addresses or older/customized incoming-mail token formats. If exposure is suspected, the associated incoming-email token should be reset through the relevant GitLab settings, which invalidates the affected project addresses. Security teams should also review the permissions of affected accounts, protected-branch configurations, CI/CD pipelines and variables, recent commits, merge requests, and audit events for suspicious activity. GitLab has updated its interface and documentation to clarify that incoming email can create both issues and merge requests, emphasize token secrecy and reset procedures, and document the IP-restriction exception, although the underlying incoming-email functionality remains available.