GitLab’s “Email work item to this project” feature, intended to simplify issue creation, has been found to expose a serious security vulnerability that allows attackers to push code directly to the main branch and execute CI/CD pipelines. Security researchers at Aikido discovered that the private email addresses GitLab provides contain long-lived authentication tokens that grant far more access than users expect, effectively bypassing traditional security controls like IP restrictions.
Modus operandi
When users click “Email work item to this project” in GitLab, they receive a unique email address containing a glimt- prefixed token that never expires. While GitLab’s interface suggests this address only creates issues within a specific project, the embedded token actually provides account-wide access across all projects the user can reach, both public and private. Attackers who obtain this email address can change the suffix from -issue@ to -merge-request@, attach a code patch, and submit it directly to any branch, including protected ones like main. If the patch modifies .gitlab-ci.yml, the attacker can execute arbitrary CI/CD jobs with the victim’s permissions, potentially exfiltrating secrets or deploying malicious code.
One of the most concerning aspects of this vulnerability is its ability to circumvent IP allowlists and other network-based restrictions. Researchers tested this against private projects configured to accept connections from only a single IP address; while GitLab correctly blocked browser access and git clone commands from unauthorized IPs, it still accepted merge request emails and pushed commits to the main branch. This creates a dangerous blind spot for organizations that believe their IP restrictions provide comprehensive protection, when in reality the email pathway offers an unguarded backdoor into their repositories.
The vulnerability affects every GitLab.com account and all self-managed instances with incoming email enabled, with no option to disable the feature. GitLab has acknowledged the issue but classified it as intended behavior rather than a security bug, making only minor UI updates to clarify that the email addresses can create merge requests in addition to issues. However, these changes still don’t adequately communicate that the token reaches every project in the account, can push code to protected branches, and bypasses IP restrictions entirely. Researchers found over a dozen publicly exposed email addresses in open-source project documentation, many deliberately published by maintainers instructing users where to send bug reports.
Mitigation strategies
Organizations should immediately rotate their incoming email tokens via the personal access tokens page, though this invalidates all project addresses simultaneously. Teams should scan repositories and documentation for exposed glimt- tokens using secret detection tools, treating these addresses with the same caution as API keys or passwords. Additionally, security teams must recognize that IP allowlists alone don’t provide complete protection in GitLab, and should implement additional controls like requiring sender address verification and monitoring for unauthorized merge requests. Until GitLab implements more granular controls or allows feature disablement, proactive token rotation and vigilant secret scanning remain the primary defenses against this attack vector.