Application security researchers at Aikido uncovered a critical exposure hidden inside standard repository documentation across popular open-source software projects, where maintainers unknowingly publish private authentication tokens embedded in automated ticketing addresses. The vulnerability stems directly from the built-in GitLab project email system. When developers configure inbound ticketing to collect error reports, the platform generates unique destination addresses designed to parse incoming messages into repository issues or tasks. Because each address embeds a permanent authentication token tied to an account, any remote sender on the internet can push unauthorized code directly into production branches without entering credentials [1].
How GitLab Project Email Addresses Handle Inbound Tasks
GitLab provides developers with an integrated capability labeled “Email work item to this project” to simplify bug intake from external contributors across public and private code repositories. When an engineer clicks this button, the platform generates a dedicated address containing a distinct authentication string formatted with a glimt- prefix that persists indefinitely. GitLab treats incoming messages sent to this address as authentic requests submitted by the token owner. Any message delivered to the destination automatically converts into a formal project issue. The system never verifies sender identity. Anyone on the internet who discovers the address can generate repository records while impersonating the account owner [1].
The embedded token never expires. Aikido researchers discovered that GitLab generates this permanent credential by default for every active user profile across GitLab.com [2].
Maintainers frequently paste these inbound destinations directly into public documentation, README files, contributing guidelines, and support portals to collect error reports from external users. Aikido audited public repositories in a single afternoon. They found a dozen live addresses. Several belonged to prominent open-source projects. Maintainers assumed the address operated as a benign public inbox restricted solely to filing bug tickets, but GitLab assigns identical permissions to the token as the developer who generated it. Because the credential persists across the entire project namespace without permission boundaries, publishing the address effectively hands complete account authority over to any malicious actor browsing the repository [1].
Converting Work Items into Unauthorized Merge Requests
A simple suffix modification transforms the destination into an unauthenticated code pipeline. While the generated address ends with an -issue suffix for logging tickets, changing that ending to -merge-request activates a completely different ingestion workflow inside the GitLab project email system. “Change the -issue suffix in the email address to -merge-request, and GitLab will open a merge request,” Aikido explained in its technical disclosure. Remote attackers need no login credentials or mailbox access to initiate this change [1].
To push code into the repository, an attacker prepares a standard git patch and names the intended branch in the email subject line. GitLab parses the incoming patch attachment and applies the code directly to that target branch. The server creates missing branches. If the token owner possesses write permissions to protected branches, the unauthorized commit lands directly on the main branch under the developer’s legitimate name without requiring secondary verification [2].
The risks multiply if the malicious patch alters the project’s .gitlab-ci.yml configuration file. When a commit touches pipeline definitions, GitLab initiates automated continuous integration jobs running under the victim’s account privileges. Adversaries can script these jobs to execute arbitrary commands, exfiltrate protected continuous integration secrets, or dump proprietary source code to external servers across the internet. Because the process executes through automated system handlers, the developer receives no standard notification that their credentials executed pipeline scripts [2].
GitLab Email Token Reaches Across Repositories
A superficial inspection suggests each inbound address links exclusively to the single project where the maintainer generated it. Research conducted by Aikido proved otherwise. Every incoming address generated for a particular user embeds the identical underlying GitLab email token. That single token operates across every repository accessible to the developer’s account, spanning both public repositories and confidential corporate workspaces where proprietary intellectual property resides [2].
Reaching a specific repository requires two additional metadata values: the project namespace path and its numeric project identifier. Public projects expose both values openly within web URLs and API endpoints, making them immediately accessible once an attacker harvests the GitLab project email credential. Private repositories require the attacker to discover the internal project path, though numeric project IDs remain sequential and simple to guess. Account permissions establish the true boundary of exploitation (such as Guest, Developer, or Maintainer). While a leaked address belonging to a user with Guest status yields minimal operational leverage, an address tied to a Maintainer role grants an adversary unrestricted access to commit code, manipulate production pipelines, and extract confidential repository issues [2].
In its official documentation, GitLab explicitly cautions engineers that incoming addresses are private credentials generated exclusively for individual accounts. The platform instructions advise users to keep tokens confidential and reset them immediately if exposure occurs. GitLab published clear documentation warnings. However, because developers commonly perceive email addresses as public contact points rather than authentication secrets, many maintainers inadvertently publish them to solicit bug submissions from external testers [1].
Bypassing Network Allowlist and Two-Factor Defenses
The severity of the flaw increases because incoming email processing operates outside conventional network boundaries. Many enterprise organizations enforce strict IP allowlists to ensure that repository changes originate solely from corporate VPN gateways. GitLab exempts incoming mail from allowlists. Corporate firewall policies do not apply. To confirm this behavior, Aikido researchers configured a private test project restricted to an isolated external IP address [2].
When researchers attempted to browse the restricted repository or perform a git clone from an unauthorized IP, GitLab blocked the connection immediately. Sending a patch to the project’s inbound email address produced a completely different result. The platform accepted the message without friction, created the merge request, and merged the commit directly into the main branch. The attack leaves no browser trace. No browser session is recorded. Furthermore, incoming email features function without two-factor authentication, bypassing mandatory multi-factor enforcement across enterprise environments [2].
This exposure affects every active account on GitLab.com as well as self-managed installations where administrators enable GitLab incoming email. In contrast, GitLab Dedicated does not appear susceptible because the inbound mail feature remains restricted to self-managed and multi-tenant deployments, though Aikido could not test Dedicated instances directly. Security engineers face similar perimeter isolation dilemmas whenever backend protocols bypass perimeter filters, as demonstrated when security teams evaluated how Google Pixel phones patched a zero-click modem flaw to eliminate unauthenticated firmware channels [2].
GitLab Incoming Email Revocation and Mitigation Steps
Aikido initially reported the vulnerability through HackerOne in May 2026, but GitLab closed the submission as intended platform behavior. Following a second confidential disclosure submitted in June 2026, GitLab updated its documentation and web interface. The vendor adjusted UI descriptions to clarify that tokens can open merge requests rather than solely creating work items. GitLab also removed previous documentation assertions claiming that tokens could not access other repository data, while adding explicit notices warning developers that inbound email handlers completely bypass IP allowlists and two-factor authentication requirements [1].
The platform did not alter core message processing rules. Tokens still do not expire automatically, GitLab still accepts messages from arbitrary external mailboxes, and individual users possess no configuration switch to disable inbound message processing on their accounts. GitLab opened an internal tracking issue to consider verifying sender mailboxes against verified account addresses. That verification check remains under consideration rather than deployed in production. Attackers can still exploit any exposed GitLab project email credential discovered online [2].
Engineers must audit repositories immediately to remove any exposed addresses from public files. Developers who inadvertently published an address should immediately navigate to the personal access tokens menu within their user profile (accessible under account user settings) to reset incoming email tokens across all projects. Resetting replaces tokens across every linked project at once, invalidating any leaked address before adversaries abuse it. On self-managed instances, system administrators can disable inbound email processing instance-wide to eliminate exposure until GitLab implements mandatory sender verification [2].
- ONLINE NEWS Toulas, B. (2026, September 24). Exposed GitLab project email addresses let attackers push code. BleepingComputer. [Article Link]
- ONLINE NEWS The Hacker News. (2026, September 23). A Leaked GitLab Issue Email Address Lets Anyone Push Code and Run CI Jobs as You. The Hacker News. [Article Link]
