GitLab Email Token Flaw Allows Code Push to Protected Repositories

A single email address, intended to let developers submit bug reports with a quick message, functions as a master key capable of bypassing corporate firewalls to alter source code. The mechanism relies on a convenience feature within GitLab that assigns users a unique incoming email address to create project issues, embedding an authentication token directly into the address string. For organizations relying on strict access controls to protect their software supply chains, the discovery that a simple contact address can authorize direct code commits represents a fundamental breach of their security architecture. The magnitude of the flaw lies in its simplicity: no complex exploitation of memory or cryptographic weaknesses is required, only the possession of an email address that many developers willingly publish in their open-source documentation.

Aikido Security researcher Joe Leon revealed on September 23, 2026, that this embedded credential, known as a glimt- token, does not expire and is not scoped to a single repository. Instead, it grants broad, account-wide access to every public and private project the user can modify. When a developer generates an incoming email address for a specific repository, GitLab embeds this universal token into the address string. Because the token is tied to the user's identity rather than the specific project where it was generated, an attacker who acquires the address gains the exact same permissions as the developer across their entire portfolio of work. This architectural decision transforms a localized convenience feature into a global credential risk.[1][2]

"The token inside this email address is essentially a fine-grained personal access token with significant access to your GitLab projects," Aikido's report stated. Because the token remains identical across all addresses generated for a specific user, exposing it in one context compromises the entire account. If a developer working on a proprietary enterprise application uses the same GitLab account to contribute to a public open-source tool, leaking the email address in the public repository provides an attacker with the credentials needed to breach the private enterprise codebase. The persistence of the token exacerbates the danger, as it remains valid indefinitely until the user explicitly navigates into their account settings to revoke and regenerate their personal access tokens.[2][4]

The exploit path leverages GitLab's workflow for handling emailed code patches. By changing the exposed email address suffix from -issue to -merge-request and attaching a .patch file, an attacker can force the platform to apply code changes to a branch named in the email's subject line. GitLab's internal systems automatically parse the incoming email, authenticate the sender using the embedded token, and execute the requested Git operations as if the developer had performed them directly. This allows threat actors to inject malicious code into software projects without ever interacting with the standard Git command-line interface or logging into the GitLab web portal, leaving fewer traces in conventional access logs.[3][5]

This method circumvents standard security perimeters entirely. Because the incoming emails are processed internally by GitLab's own servers, the requests ignore external IP allowlists and bypass two-factor authentication requirements that would normally block unauthorized logins. Enterprise security teams frequently deploy strict network controls, ensuring that code can only be pushed from corporate VPNs or specific office locations. However, the email-to-merge-request pipeline operates outside these boundaries. When GitLab receives the email, it processes the payload from its own internal network, effectively tunneling the attacker's code through the organization's firewall and rendering perimeter-based defenses useless against this specific vector.[5]

Testing the flaw against a locked-down private repository, Aikido demonstrated the severity of the bypass. "GitLab blocked our browser and rejected git clone," the researchers noted. "It accepted the email, and the commit landed on main." This confirmation that the vulnerability allows direct pushes to protected branches like main highlights the critical nature of the exposure. Branch protections are designed to enforce code review policies and prevent unvetted changes from reaching production environments. By accepting emailed patches directly to these branches, the platform overrides the very governance controls that development teams rely on to maintain the integrity of their software releases.[1][5]

The risk extends beyond modifying application source code. Malicious commits can alter .gitlab-ci.yml configuration files to trigger Continuous Integration and Continuous Deployment jobs, allowing attackers to exfiltrate environment variables and infrastructure secrets. Modern software development relies heavily on automated pipelines that possess highly privileged access to cloud environments, databases, and deployment servers. By pushing a modified pipeline configuration via email, an attacker can instruct GitLab's runners to print out AWS keys, database passwords, or signing certificates. This lateral movement transforms a code-level vulnerability into a full-scale infrastructure breach, granting threat actors the keys to the organization's broader cloud architecture.[4]

The vulnerability is amplified by how developers actively use the feature. In a single afternoon, Aikido researchers found a dozen live GitLab incoming email addresses deliberately published in the public README files and contributing guides of popular open-source projects. Maintainers frequently include these addresses in their documentation to provide a frictionless way for users to submit bug reports or feature requests without needing to create a GitLab account. Unaware that the address contains an account-wide master token, developers effectively publish their passwords on the public internet, creating a massive, easily searchable attack surface for automated scanners and supply chain threat actors.[1][3]

"Any mailbox on the internet can send to that address, and GitLab processes the message as the token's owner," the researchers explained, emphasizing that possessing the address provides an attacker with both authentication and authorization simultaneously. Unlike traditional phishing attacks that require tricking a user into handing over credentials, this vulnerability requires no user interaction once the address is exposed. The attacker simply sends an email from any standard mail client or automated script, and GitLab's infrastructure blindly trusts the embedded token, executing the payload with the full authority of the compromised developer's account.[2]

Aikido initially reported the behavior to GitLab via the HackerOne bug bounty platform in May 2026. GitLab closed the ticket, classifying the broad access granted by the email tokens as intended behavior rather than a security flaw. This response underscores a fundamental tension in platform design between user convenience and secure defaults. From the platform's perspective, the email addresses were operating exactly as programmed, facilitating remote project management. However, security researchers argue that failing to scope the tokens to individual projects or enforce IP restrictions creates an unreasonable burden on users who cannot be expected to understand the hidden architectural risks of a simple contact address.[2][4]

Following a confidential issue filed in June, GitLab opened a merge request on July 28 to update its user interface. The platform removed previous documentation claiming the token "cannot be used to access any other data," clarifying the actual scope of the credential. The updated interface now explicitly warns users that the incoming email token provides extensive access to their account and should be treated with the same secrecy as a password. While this transparency improves user awareness, it places the entirety of the security responsibility on the developer, requiring them to actively manage and protect a credential that the platform generates automatically.[2][4]

GitLab has not disabled the underlying email functionality, though it is reportedly considering a requirement that the sender's email matches the GitLab account owner. For now, the only mitigation is for developers to manually rotate their access tokens and scrub the addresses from public documentation. Security teams are advised to scan their codebases and public repositories for exposed glimt- strings and preemptively reset tokens for their engineering staff. Until structural changes are implemented to restrict the token's scope or enforce network boundaries, the email-to-push pipeline remains a potent, active vector for software supply chain compromise.[2][4]