GitLab Email Token Allows Unauthorized Code Commits

A leaked GitLab email token lets attackers commit code and run jobs as you, bypassing two-factor authentication.
Key points
- GitLab's private issue email token acts as a permanent credential for all user projects.
- Attackers can use the token to commit code and run CI jobs without 2FA.
- Users must reset their incoming email token to invalidate any leaked addresses.
Aikido Security revealed a security flaw in GitLab that exposes users to account takeover. The private email address used for filing issues acts as a permanent credential. If this address leaks, anyone can use it to commit code and run automated jobs in your name. This happens without needing your password or two-factor authentication.
The vulnerability affects every GitLab.com account and self-managed instances with incoming email enabled. The feature is turned on by default for most users. Aikido demonstrated that an attacker can use the token to push changes to the main branch. They can also trigger CI/CD pipelines that execute as the legitimate user. This grants access to sensitive secrets and protected branches.
One Token Controls All Projects
GitLab assigns a unique token to each user's email address. This token is tied to your account, not a specific project. Aikido found that the same token works across all projects you can access. Whether a project is public or private, the token remains valid. This means one leaked address gives broad access to your entire workspace.
The address appears to belong to a single project, which is misleading. In reality, it functions as a master key for your account. GitLab does not verify the sender of the email. It processes the message as if it came from you. This design choice creates a significant risk for any exposed credential.
Bypassing Security Checks and Limits
Incoming email traffic is exempt from IP address restrictions. This allows attacks to originate from anywhere in the world. Aikido tested this by locking a project to a specific IP. GitLab blocked their browser and clone attempts. However, it accepted the merge request email. The commit landed on the main branch successfully.
The process also skips two-factor authentication. GitLab documentation states that incoming email features work without 2FA. This is true even on instances that require it for other actions. The attacker only needs the email address and the target branch name. They attach a patch file and send it. GitLab applies the changes automatically.
Resetting Tokens to Secure Accounts
Users can mitigate this risk by resetting their incoming email token. This action replaces every project address at once. Any previously shared address will stop working immediately. You must update any tools or guides that rely on the old address. Aikido found about a dozen live addresses published online. Most were shared intentionally for bug reporting.
The severity of the breach depends on your role. A Guest account token offers limited access. A Maintainer token can access protected branches and CI/CD secrets. The Hacker News reported that this flaw requires no special privileges beyond the token. Users should audit their public profiles and documentation. Remove any exposed email addresses to prevent unauthorized code execution.






