Security researchers have uncovered a GitLab behavior that could let attackers use a leaked project email address to push code, trigger CI/CD jobs and reach other repositories accessible to the address owner.

Aikido Security researcher Joe Leon detailed the attack path this week in a blog post after reporting it to GitLab earlier this year. The issue involves GitLab’s incoming email token, a credential embedded in private email addresses that GitLab provides for creating issues and merge requests by email.

“The token inside this email address is essentially a fine-grained personal access token with significant access to your GitLab projects,” the report said.

GitLab’s documentation says the token never expires and warns that anyone who obtains it can create issues and merge requests as the user. GitLab also allows users to attach .patch files when creating merge requests by email. GitLab applies the patches to the named source branch or creates the branch if it does not already exist.

Aikido found that the same incoming email token appeared in addresses generated for different projects belonging to one user. The researchers said an attacker who obtained one of those addresses could change its suffix from -issue to -merge-request, attach a patch and submit code using the victim’s existing GitLab permissions.

The same mechanism can also turn a leaked email token into a path for CI/CD execution. Aikido demonstrated adding a job to .gitlab-ci.yml via an emailed patch, causing GitLab to run a pipeline as the victim. Aikido also showed how to use the same access to exfiltrate private source code, read CI/CD variables and secrets, and use a job’s CI_JOB_TOKEN to access additional GitLab resources permitted to that job token.

The attack is constrained by the victim’s existing GitLab permissions and by the attacker’s knowledge of the target project. The incoming email token does not elevate privileges. Aikido said an address tied to a Guest account would have little value for these attack paths, while one tied to a Maintainer could potentially expose protected branches and CI/CD variables, depending on the project’s configuration. Reaching another project also requires its project path and ID. GitLab exposes both for public projects, but going after a private project would require the attacker to obtain identifying information about it through another leak.

Aikido reported the behavior through HackerOne in May and said the report was initially closed as intended behavior. Aikido said it filed a confidential GitLab issue in June, after which GitLab updated its interface and documentation. A GitLab merge request opened July 28 said previous descriptions of the token were inconsistent and updated them to more accurately explain its capabilities and emphasize that the token should remain private.

So far, GitLab has responded by making the token’s capabilities and risks clearer but has not disabled the underlying email functionality. Users who believe one of these addresses has been exposed can reset the token from GitLab’s personal access token settings, which invalidates addresses containing the previous token. For organizations that rely on email-created issues or merge requests, the disclosure is a reminder that exposing those addresses can allow actions under the account owner’s existing GitLab privileges.