Security Researchers Uncover High-Risk GitLab Attack Vector Linked to Leaked Project Email Tokens

Executive Overview

In the interconnected and fast-paced ecosystem of modern software development, security is frequently challenged by subtle design choices intended to maximize user convenience. A recent discovery by security researchers at Aikido Security has brought this ongoing tension into sharp focus, exposing a security concern within GitLab’s incoming email handling.

According to findings detailed by Aikido researcher Joe Leon, an attacker who obtains a user’s leaked GitLab project email address can leverage it to execute arbitrary code, trigger continuous integration and continuous deployment (CI/CD) pipelines, and access sensitive repositories well beyond the scope of a simple correspondence channel.

At the heart of the issue is GitLab’s incoming email token—a persistent, non-expiring credential embedded directly inside the private email addresses that the platform provides to users for creating issues and merge requests remotely. Far from being a benign utility address, this token functions effectively as a fine-grained personal access token (PAT). It carries significant operational permissions tied directly to the account owner’s credentials.

By manipulating these project email addresses—converting an issue-creation address into a merge-request vector, appending malicious .patch files, and injecting instructions into .gitlab-ci.yml files—an external threat actor can orchestrate unauthorized code pushes, harvest sensitive environment variables, and pivot into adjacent repositories.

While the attack surface is bounded by the specific permission tiers of the victim and requires prior knowledge of target project identifiers, the implications for enterprise security are profound. The disclosure highlights the critical need for developers and organizations to treat automated project email addresses with the same rigorous access control and confidentiality standards typically reserved for high-privilege API keys, passwords, and administrative access tokens.

Detailed Chronology: From Discovery to Documentation Update

The journey of this security insight from initial observation to public disclosure spans several months and highlights the often-complex friction between automated utility features and real-world threat modeling.

The Initial Discovery and HackerOne Submission

In early 2024, Joe Leon and the research team at Aikido Security began examining how platform-generated inbound email addresses interact with underlying repository permissions. They noted that the tokens embedded within these addresses remained active indefinitely, defying the common security best practice of token rotation and expiration.

Recognizing the potential for abuse—specifically how an incoming email token could be repurposed to perform unauthorized code-push operations—Aikido officially reported the behavior through HackerOne in May.

Initially, the report was closed by platform triage as "intended behavior." From an architectural standpoint, GitLab designed these incoming addresses to permit authenticated interactions via email, allowing developers on the go to interact with their project boards without logging into the web interface. However, the design assumption underestimated how easily these email addresses could leak through accidental public code commits, public issue trackers, or misconfigured communications channels, and how seamlessly an attacker could pivot from sending an issue description to injecting code.

Escalation and the Confidential GitLab Issue

Undeterred by the initial HackerOne closure, Aikido researchers pursued further verification of the attack paths. In June, they filed a confidential GitLab issue, providing concrete demonstrations of how a leaked token could be abused to trigger CI/CD pipelines and exfiltrate sensitive data.

This direct escalation prompted a re-evaluation of the feature’s risk profile within GitLab’s security engineering teams. Rather than disabling the incoming email functionality outright—which would disrupt workflows for teams heavily reliant on email-based issue tracking—GitLab opted for a transparency and documentation-first remediation strategy.

Interface Updates and Documentation Revisions

Throughout July, GitLab moved to clarify the scope, capabilities, and inherent risks associated with incoming email tokens. On July 28, a GitLab merge request was opened to address what developers acknowledged were inconsistent previous descriptions of the token.

The updated documentation explicitly warns users that incoming email addresses contain powerful credentials that should be treated as private secrets. Furthermore, GitLab updated its web user interface to ensure that users are better informed about how these tokens operate and where they are utilized across different projects.

Technical Deep Dive: How the Exploit Unfolds

To fully understand the severity of this behavior, it is necessary to examine the mechanics of GitLab’s incoming email architecture and the step-by-step path an attacker might take to weaponize a leaked address.

The Anatomy of the Incoming Email Token

GitLab allows users to generate unique email addresses for specific projects. These addresses are typically formatted to route inbound messages directly to the platform, automatically parsing the content to open a new issue or append a comment. Embedded within the local-part of the email address is a secret token.

Aikido’s research revealed two critical design characteristics of these tokens:

1. Cross-Project Consistency: The exact same incoming email token often appeared across different project addresses generated for a single user. If an attacker managed to acquire one project email address belonging to a user, they frequently gained access to the token valid across multiple other projects managed by that same individual.
2. Infinite Lifespan: Unlike modern OAuth tokens or short-lived CI job tokens, these email-embedded credentials do not automatically expire. They remain valid indefinitely until the user manually resets their personal access tokens or revokes the underlying mechanism.

Step 1: Altering the Vector from Issue to Merge Request

GitLab supports creating merge requests via email by attaching standard .patch files to an incoming message. When received, GitLab processes the patch, applying it to a specified source branch or automatically generating a new branch if the designated one does not already exist.

An attacker who has acquired a victim’s project email address—originally intended for issue creation (often ending with a -issue suffix)—can simply alter the suffix to -merge-request. Because the underlying token remains identical and valid, the modified email address bypasses traditional authentication boundaries and masquerades as the victim.

Step 2: Injecting Malicious Code and Triggering CI/CD Pipelines

Once the malicious merge request channel is established via email, the attacker attaches a crafted .patch file containing arbitrary code modifications.

Aikido demonstrated that this method can be used to modify critical repository files, such as .gitlab-ci.yml. By successfully committing a change to the CI/CD configuration file through an emailed patch, the attacker tricks GitLab into automatically executing a pipeline under the security context and identity of the victimized user.

Step 3: Data Exfiltration and Lateral Movement

The execution of a compromised CI/CD pipeline opens the door to extensive secondary impacts:

• Source Code Exfiltration: With the ability to run arbitrary jobs, an attacker can write pipeline scripts designed to read and exfiltrate private source code repositories accessible to the victim.
• Secret Harvesting: CI/CD environments frequently mount sensitive environment variables, API keys, and deployment credentials. An unauthorized pipeline can capture these secrets and transmit them to an external, attacker-controlled server.
• Resource Pivoting via CI_JOB_TOKEN: By leveraging the job’s native CI_JOB_TOKEN, the executing process can interact with additional GitLab API resources and other repositories that the job token is permitted to access, effectively widening the breach radius across the organization’s entire GitLab instance.

Constraints and Boundary Conditions

While the attack path is technically sophisticated and dangerous, security analysts note that it is bound by specific constraints:

• Permission Dependency: The attack cannot elevate privileges beyond what the victim account is already authorized to perform. If the victim holds only a Guest role, the exploit is largely neutralized because guests cannot push code or trigger privileged CI/CD jobs. Conversely, if the victim is a Maintainer or Owner, the attack can expose protected branches, critical environment variables, and administrative controls.
• Project Identifier Knowledge: To target a specific project, the attacker must know its exact project path and ID. While public project IDs and paths are trivial to discover, targeting a private project requires the attacker to have previously harvested identifying metadata through an entirely separate intelligence-gathering phase or leak.

Supporting Context & Metrics: The Human and Systemic Factors

The discovery underscores a broader, recurring theme in application security: the friction between usability features designed for developer velocity and the principle of least privilege.

The Prevalence of Credential Leaks

Project email addresses often find their way into public view through several common channels:

• Accidental Commits: Developers occasionally hardcode or log configuration strings, including notification endpoints and integration email addresses, directly into public repositories.
• Support and Issue Discussions: In collaborative environments, team members may paste raw configuration snippets or error logs into shared communication tools (such as Slack, Microsoft Teams, or public forums) without sanitizing embedded tokens.
• Log Aggregation and Monitoring Systems: Centralized logging platforms often capture inbound webhook payloads or email gateway traffic, inadvertently storing raw token strings where they can be accessed by a wider internal audience or compromised via lateral movement within enterprise networks.

The Risk Profile of "Silent" Credentials

Unlike traditional passwords or interactive login sessions—which often trigger alerts, Multi-Factor Authentication (MFA) prompts, or anomalous login notifications—automated tokens like GitLab’s incoming email credentials operate silently in the background. Because they are designed for machine-to-machine or system-to-system asynchronous communication, their usage rarely prompts an immediate behavioral challenge. Consequently, malicious activity conducted via a leaked email token can blend seamlessly into normal development operations, complicating incident response and forensic investigations.

Official Statements and Industry Response

The handling of this vulnerability by both Aikido Security and GitLab illustrates the evolving dynamics of responsible disclosure in the modern DevSecOps landscape.

Aikido Security’s Perspective

Aikido researchers emphasized that while GitLab’s decision to maintain the core email functionality was disappointing from an absolute zero-risk standpoint, the transparency improvements represent a meaningful step forward.

"The token inside this email address is essentially a fine-grained personal access token with significant access to your GitLab projects," Aikido noted in its published analysis.

The security firm urged organizations to audit their internal communication habits, treat all platform-generated integration endpoints as sensitive credentials, and educate engineering teams on the hidden privileges attached to routine collaboration tools.

GitLab’s Remediation Strategy

Rather than deprecating email-based issue and merge request creation—which remains a valued workflow for teams operating in constrained network environments or utilizing mobile workflows—GitLab chose to address the root cause through enhanced user awareness and clearer documentation.

By updating its official security guidelines, GitLab explicitly reinforced that:

1. Incoming email addresses must be kept strictly confidential.
2. The tokens embedded within these addresses carry the same operational weight as personal access tokens with corresponding project scopes.
3. Users possess the capability to invalidate compromised tokens directly via their personal settings.

Mitigation and Remediation Strategies for Organizations

Securing development pipelines against token-based attacks requires a combination of proactive hardening, continuous monitoring, and rapid incident response protocols. Organizations utilizing GitLab and similar DevOps platforms should implement the following best practices:

1. Token Auditing and Rotation

Administrators and individual developers should regularly review active personal access tokens and project integration endpoints. If there is any suspicion that a project email address has been exposed in public logs, chat channels, or code repositories, users should immediately reset their personal access tokens from their GitLab settings page. Resetting these tokens automatically invalidates any legacy email addresses containing the compromised token string.

2. Adoption of the Principle of Least Privilege

Organizations must rigorously enforce role-based access control (RBAC) across all repositories:

• Limit user accounts to the minimum necessary permission tier required for their daily responsibilities.
• Avoid granting broad Maintainer or Owner privileges to accounts that do not strictly require them, thereby shrinking the potential blast radius should an integration token or personal credential be compromised.

3. Automated Secret Scanning

Integrate robust secret scanning tools into both the local development environment (pre-commit hooks) and the CI/CD pipeline. These tools should be configured to scan not only for traditional API keys and private certificates but also for platform-generated URLs, webhook endpoints, and incoming email addresses containing sensitive tokens.

4. Continuous Pipeline Monitoring

Security operations centers (SOCs) and DevSecOps teams should monitor CI/CD pipeline execution logs for anomalous behavior. Sudden spikes in pipeline triggers originating from unfamiliar sources, unexpected modifications to .gitlab-ci.yml files, or unauthorized attempts to access environment variables should trigger immediate automated alerts and pipeline quarantines.

Future Outlook: The Evolution of DevSecOps Security

As software supply chains become increasingly complex and distributed, the boundary between developer productivity tools and security perimeters continues to blur. The GitLab incoming email token disclosure serves as a timely case study for the industry at large.

Looking ahead, platform architects and security researchers alike anticipate several key shifts in how integrated development platforms manage automated communication channels:

• Granular Expiration Policies: Platforms are expected to move away from permanently persistent utility tokens, introducing mandatory expiration windows and automated rotation mechanisms for integration endpoints.
• Context-Aware Verification: Future iterations of inbound communication parsers may incorporate contextual verification steps—such as secondary confirmation prompts or IP-allowlisting—before permitting automated code execution or patch application via asynchronous channels.
• Holistic Threat Modeling: Security reviews of developer platforms will increasingly focus not just on traditional authentication portals, but on every peripheral utility channel—including email gateways, webhooks, and chatops integrations—that possesses the capability to influence source code integrity.

Ultimately, while convenience will always remain a driving force in software engineering, incidents like this remind the development community that security cannot be treated as an afterthought. Protecting modern codebases requires comprehensive visibility, disciplined credential management, and an acute awareness that every communication channel is a potential attack surface.