GitLab email tokens allow code pushes and CI execution without authentication

Security researchers at Aikido Security have identified a significant vulnerability in GitLab’s incoming email feature that allows attackers to push code and execute CI/CD jobs using only a leaked email address. Reported in mid-2026, this flaw affects both GitLab.com and self-managed instances where incoming email is enabled, effectively treating a static email token as a high-privilege credential that bypasses standard security controls like two-factor authentication and IP allowlists.

What happened

The core of the issue lies in how GitLab handles email-to-work-item conversions. Every user account on GitLab is assigned a unique, non-expiring token embedded within an email address used for filing issues. While this address appears specific to a single project, Aikido Security discovered that the underlying token is shared across all projects accessible by that user. Consequently, anyone who obtains this email address can interact with any public or private project the user has access to, regardless of which project originally displayed the address.

The vulnerability escalates beyond simple issue creation. By modifying the email address suffix from -issue to -merge-request, an attacker can submit patches directly to a repository. If the attacker knows the target project’s path and numeric ID, they can send an email with a code patch attached. GitLab processes this email as a merge request, applying the patch to the specified branch. If the user has permission to push to that branch, including protected branches like main, the code is committed under the user’s identity. Furthermore, if the patch modifies the .gitlab-ci.yml file, GitLab will execute the resulting CI/CD jobs with the user’s permissions, potentially exposing secrets or compromising infrastructure.

Key details

• Shared Token: The email token is identical for all projects a user can access, meaning a leak from one project compromises access to all others.
• No Sender Verification: GitLab does not verify the sender’s email address against the account owner, allowing any mailbox to act as the user.
• Bypasses Security Controls: Incoming email actions are exempt from IP restrictions and two-factor authentication requirements, even if enforced elsewhere.
• Privilege Dependent: The impact scales with the user’s role; Guest accounts have limited impact, while Maintainers can push to protected branches and access CI secrets.
• Target Identification: Attackers need the project path and numeric ID in addition to the token, though IDs are easily guessable and paths are often public.
• No User-Level Disable: Individual users cannot turn off email-based issue or merge request creation; only instance administrators can disable the feature globally.

Background

GitLab’s incoming email feature is designed to streamline workflow by allowing users to create issues or merge requests via email clients. This is particularly useful for teams that manage triage through email interfaces or want to lower the barrier for external contributors to report bugs. The system relies on a unique email address for each user-project combination, which contains a hidden token that authenticates the action.

However, authentication tokens generally require strict confidentiality and rotation policies. In this case, the token is static and never expires. While GitLab treats this as a standard credential, its integration with the email system creates a blind spot. Traditional security measures like IP whitelisting, which restricts access to known networks, do not apply to incoming email traffic. Similarly, two-factor authentication (2FA), which adds a second layer of verification for logins, is bypassed because the email system trusts the token implicitly without challenging the sender.

Why it matters

For teams running self-hosted GitLab instances or using GitLab.com, this vulnerability highlights a critical gap in supply chain security. Developers often share contact information in README files, contributing guides, or support pages to facilitate bug reporting. If these documents contain the special GitLab email address, they inadvertently publish a credential that grants code write access. Aikido Security found approximately a dozen such live addresses published openly, including in widely used open-source projects.

The ability to bypass IP restrictions is particularly concerning for enterprises that rely on network-level security to protect their codebases. An attacker outside the corporate network can still push malicious code to the main branch if they possess the email token. This undermines the assumption that internal-only branches are safe from external threats. Additionally, the execution of CI/CD jobs as the compromised user can lead to further lateral movement within the infrastructure, especially if those jobs have access to deployment keys or cloud credentials.

What you can do

• Reset your token: Go to your personal access tokens page in GitLab and reset your incoming email token. This invalidates all existing project addresses immediately.
• Audit public documentation: Search your project READMEs, contributing guides, and support pages for any posted GitLab email addresses and remove them.
• Disable incoming email: If you are an administrator of a self-managed instance, consider turning off the incoming email feature globally if it is not essential for your workflow.
• Monitor merge requests: Keep a close eye on merge requests created via email, especially those targeting protected branches or modifying CI configuration files.
• Educate team members: Inform developers that the email address shown in the "Email work item" button is a sensitive credential, not just a contact method.
• Check for leaks: Use tools or manual searches to see if your organization’s GitLab email addresses have been posted on public forums or code repositories.