GitLab Email Token Vulnerability Exposes Code and CI Access
Leaked email addresses allow unauthorized code commits and CI job execution.
1Email tokens act as credentials
GitLab's issue email addresses contain non-expiring tokens tied to user accounts. These tokens grant the same permissions as the user across all projects, public or private. Aikido Security discovered that tokens from different projects are identical, creating a single point of failure. The vulnerability affects both GitLab.com and self-managed instances with default email settings.
2Full impersonation capabilities
Attackers with the email address can commit code to any branch the victim can access, including main. They can also trigger CI/CD jobs running with the victim's permissions. GitLab processes these emails without sender verification or IP restrictions. The system treats such requests as legitimate user actions, bypassing standard security checks.
3Merge request exploitation
Aikido demonstrated how attackers can submit malicious code via email attachments in merge requests. While the merge request targets the original project, the payload comes through attached patches. This method allows code injection even when direct project forks are restricted. The attack vector remains effective against projects with IP allowlists.
4Permission-based impact variation
The severity depends on the victim's role. Guest account tokens offer limited access, while Maintainer tokens expose protected branches and CI secrets. Attackers need the project path and ID for targeted attacks, which are publicly available for open projects. Private projects require additional information leaks but remain vulnerable to guessing attacks.
5Security bypass techniques
The email channel circumvents multiple security layers. It ignores IP restrictions and bypasses two-factor authentication, even on instances requiring 2FA. Aikido tested this by locking a project to a specific IP, which blocked browser access but accepted email-based commits. GitLab's documentation confirms these exceptions for email features.
6Enterprise-wide exposure
Every GitLab.com account contains this vulnerability by default. Self-managed instances with enabled email features (default on GitLab.com) are equally affected. Only GitLab Dedicated appears unaffected as it lacks the email feature. The risk extends to organizations using GitLab for sensitive development work.
7GitLab's response and limitations
After Aikido's June 2026 report, GitLab updated documentation but didn't fix the behavior. The company considers adding sender verification but hasn't implemented changes. Users can't disable the feature individually. GitLab maintains this is standard token behavior, arguing that leaked credentials always pose risks.
8Broader security implications
This vulnerability highlights systemic issues in developer tool security. The persistence of non-expiring tokens and lack of sender verification create long-term risks. As enterprises increasingly rely on CI/CD pipelines, such flaws can compromise entire software supply chains. The case underscores the need for principle of least privilege in DevOps tools.
Original article: The Hacker News — GitLab Email Token Vulnerability Exposes Code and CI Access