GitLab’s “Email work item to this project” feature includes a hidden risk that could allow attackers to inject code into private repositories. Researchers at Aikido Security uncovered that the private email address used for submitting work items carries a permanent token—dubbed the glimt-incoming-emailtoken—that never expires. Possession of this token grants the ability to open issues or merge requests under the account that owns the token. GitLab documents verify the existence and power of this token.
Although users see project-specific addresses when using the email work item feature, Aikido found that all addresses embed the same account-level token across different projects. Attackers who obtain the email address can replace the “-issue” suffix with “-merge-request,” attach a Git patch, and in many cases specify the target branch directly in the email subject line. GitLab then either applies the patch to the indicated branch or creates that branch using the permissions of the token owner.
Why This Flaw Matters
Users with higher permissions—such as Maintainers—face especially serious threats. If a Maintainer’s token is exposed, it may allow commits to protected branches (including main), making it appear as though the token owner made those changes. The scope of damage depends on the user’s project role and the configuration of CI/CD pipelines. Modifying .gitlab-ci.ymlcould yield execution of attacker-controlled CI/CD workflows, potentially exposing sensitive variables or secrets. Even users with lower privileges can exploit the flaw, though their power remains constrained by their permissions.
An additional complication: GitLab does not enforce IP-based restrictions on emails sent via this mechanism. That means even if a project has rigid network allowlists blocking certain IPs from accessing the repo via browser or cloning, those same restrictions do not apply to patches sent over email. Attackers may bypass those protections if they get hold of the token.
What GitLab Has Changed
GitLab acknowledges the design and behavior are intentional rather than standard bugs. Following the findings, it updated its interface and documentation to clarify the capabilities and implications of incoming email tokens. The updates now explicitly cover both issues and merge requests, stress the importance of keeping those addresses secret, explain when to reset tokens, and highlight that IP restrictions do not apply to incoming email workflows. However, the underlying email mechanism with its risks remains intact.
To guard against misuse, affected users should scan systems—repositories, public docs, tickets, logs—for exposed glimt-addresses or any customized incoming-mail token formats. Those who suspect their token is compromised should reset the incoming email token via personal access token settings; this action invalidates existing project email addresses relying on that token. Organizations should also review user permissions, protected branch configurations, pipeline setups, variable and secret access, and recent audit logs. Treat email-derived project addresses as credentials, not mere contact points.
While no public exploit has been reported yet, this gap demonstrates how deeply email and token-based workflows can undermine security expectations. Expectations that IP allowlists block all unwanted access, for example, fail where email bypasses those checks. For private or high-risk projects, minimizing reliance on such features, keeping the token secret, and limiting who can trigger merge requests or patches via email are critical mitigation steps.
What this means:This is not just an obscure token issue—it highlights how automated workflows and email-based tools become attack vectors when security boundaries aren’t aligned. Going forward, organizations using GitLab should audit their workflows, token exposure, and access permissions now, and monitor for unintended consequences. Watching whether GitLab adds stronger verification—such as enforcing sender identity or optional token expiration—will be crucial for improving the trust model around these email-based features.
