A GitLab feature designed to let users create work items through email can be abused as an account-level code delivery mechanism, potentially allowing attackers to push commits to protected branches and execute CI/CD pipelines when a private incoming-email address is exposed.
Security researcher Joe Leon of Aikido Security found that GitLab’s “Email work item to this project” option generates an address containing a long-lived incoming email token.
Although GitLab presents the address as a project-specific method for creating issues, the embedded credential can apply across every project the affected user can access.
GitLab Email Feature Lets Attackers Push Code
The address follows a format similar to incoming+project-id-glimt-<token>-issue@incoming.gitlab.com. The glimt- value acts as an authentication token that does not expire by default.
Aikido’s research found that the same token appears in email addresses generated for multiple projects, including private repositories, making it an account-scoped credential rather than a project-scoped one.
An attacker who obtains a victim’s incoming-email address can reportedly change the address suffix from -issue to -merge-request and submit a Git patch as an attachment.
By specifying a source branch in the email subject, the attacker can cause GitLab to apply the patch to an existing branch or create a new branch under the victim’s identity.
If the target account is authorized to push to a protected branch, the attacker may be able to commit directly to branches such as main. The impact escalates when the supplied patch modifies .gitlab-ci.yml, enabling an attacker-controlled pipeline job to execute within the victim’s project context.
Depending on the project’s CI/CD configuration, that job could access source code, CI/CD variables, secrets, and the CI_JOB_TOKEN available to running jobs.
The reported issue also undermines assumptions around GitLab IP allowlists. Aikido tested the technique against a private project restricted to a single IP address.
While GitLab blocked browser access and Git clone operations from the researcher’s network, it accepted the incoming merge-request email and processed the attached patch.
GitLab documentation now explicitly states that incoming email is not subject to IP restrictions for issue and merge-request creation.
Exploitation still depends on the compromised account’s permissions. A leaked address associated with a Guest account offers limited value, while a Maintainer-level account could potentially reach protected branches, alter CI configurations, and access sensitive pipeline data.
Attackers must also know the target project’s path and numeric project ID. Those details are readily available for public repositories, while targeting private projects would generally require additional information disclosure.
GitLab reportedly updated its interface after disclosure by clarifying that the email address can create both issues and merge requests, and by removing language claiming the token could not access other data.
However, the underlying behavior remains: the token does not expire, GitLab does not require the sender to match the account owner’s verified email address, and users cannot individually disable the capability. GitLab is considering sender-address verification.
Organizations should treat every GitLab incoming-email address as a sensitive credential. Security teams should search repositories, READMEs, support pages, issue templates, documentation, and logs for glimt- tokens and legacy incoming-email formats.
Any exposed token should be reset immediately through GitLab’s personal access token settings, understanding that a reset invalidates all associated project email addresses.
Teams should also review protected-branch permissions, CI/CD variable exposure, pipeline logs, and recent commits for signs of misuse.
Join 16,000+ SOC teams using ANY.RUN to streamline threat investigations and reduce manual effort. Explore for your team
