GitLab Email Token Vulnerability Exposes CI/CD Pipelines
A seemingly mundane feature designed for emailing issue tasks has proven to be alarmingly akin to a fully privileged account, belying its innocuous interface. Joe Leon from Aikido Security demonstrated that a private GitLab email address harbors a persistent token. This token empowers anyone possessing it to commit code directly to repositories and trigger automated CI/CD build and deployment pipelines under the owner’s identity.
GitLab provisions users with a personalized email address for the specific purpose of creating issues via email. Embedded within this address lies a string prefixed with ‘glimt-‘, which the platform utilizes as an incoming email token. Official GitLab documentation stipulates that this token lacks an expiration date and must remain strictly confidential, as any individual who acquires it can forge issues and merge requests masquerading as the token’s legitimate owner.
The Universal Reach of the ‘glimt-‘ Token
Leon discovered that while the email address appears exclusively bound to a single project, the underlying token possesses far broader authority. When generating this email function across disparate projects within the same account, the project-specific segments of the address fluctuate; however, the core ‘glimt-‘ token remains completely static. Consequently, its sweeping privileges extend to every project the user’s account can currently access. If you need details on how privileges work, you can review how GitLab defines access and permissions.
To escalate from merely creating an issue to actively manipulating code, an adversary simply replaces the ‘issue’ suffix within the email address with ‘merge-request’. GitLab is inherently engineered to accept ‘.patch’ files attached to such emails and seamlessly apply those modifications to the source branch. The target branch’s name is conveniently dictated by the email’s subject line. Provided the specified branch exists and the token’s owner holds the requisite authorization to commit there, GitLab dutifully integrates the commit under their guise. For a deep dive into this mechanism, you can read the full report on how a GitLab email can push to main.
Bypassing Network Security and IP Restrictions
During a strictly controlled exercise, the Aikido team specified ‘main’ in the subject line and attached a meticulously crafted ‘.patch’ file. The commit flawlessly merged into the primary branch of a private repository. If these illicit modifications alter the ‘.gitlab-ci.yml’ file, and the compromised user possesses the authority to initiate pipeline jobs, an attacker can effortlessly execute arbitrary CI/CD code. Subsequently, they could attempt to exfiltrate accessible environment variables and deeply guarded secrets, or actively weaponize the ‘CI_JOB_TOKEN’.
Furthermore, this email-based vector effortlessly circumvents the network barriers upon which system administrators frequently rely. In a deliberate test scenario, a project was restricted to permit access exclusively from a single, external IP address. While the web interface and standard ‘git clone’ commands originating from Leon’s machine immediately failed, GitLab astonishingly accepted the email payload without hesitation. The platform’s own documentation explicitly confirms that incoming email traffic remains entirely exempt from standard IP filtering constraints.
Role-Based Limitations and Mitigation Strategies
Crucially, this specific scenario does not spontaneously elevate privileges in isolation. The destructive potential hinges entirely upon the compromised address owner’s inherent role: a ‘Guest’ user’s token is virtually useless for code manipulation, whereas a ‘Maintainer’ address can surrender access to heavily fortified branches and highly sensitive CI/CD infrastructure. To successfully assault a different private project, the adversary must also ascertain its precise internal path and unique identifier.
Aikido unearthed roughly a dozen active, functional incoming email addresses scattered across public documentation and project README files. In several instances, developers had intentionally published these addresses as direct contact points for bug submissions. Prior to releasing their findings, the security team responsibly alerted all affected owners. Currently, there exists no concrete evidence of this mechanism being actively weaponized in the wild, and all demonstrations were strictly confined to repositories under Aikido’s direct supervision.
This severe vulnerability was initially reported via HackerOne in May 2026, yet the submission was dismissively closed, categorized merely as intended system behavior. Following a subsequent, more pressing inquiry in June, GitLab quietly amended its interface and documentation. They excised the erroneous assertion that accessing other data was impossible, explicitly mentioned the potential for merge requests, and documented the glaring exemption for IP filters. However, the fundamental mechanism governing email-based code commits remains completely unchanged.
This profound discovery possesses no formal CVE designation, lacks a dedicated software patch, and commands no official security bulletin. According to Aikido’s rigorous assessment, this perilous scenario threatens all GitLab.com accounts and self-hosted installations where the incoming email feature remains active; the team has not yet evaluated the GitLab Dedicated environment. If there is even a remote possibility that this address has been exposed, Aikido vehemently advises users to immediately reset their incoming email token and actively scan their repositories for these addresses, treating them with the same utmost severity as exposed cryptographic secrets.
This particular risk appears exceptionally pronounced when juxtaposed against other recent turbulence surrounding GitLab; just this September, malicious actors aggressively assaulted servers leveraging a distinct, critical vulnerability, CVE-2026-85706. Aikido’s pioneering research illuminates an entirely different class of peril, demonstrating that devastating actions require no complex software flaw when the email credentials themselves are inadvertently surrendered to the public domain.
Support Our Threat Intelligence
If you find our technology report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
