A security researcher disclosed on September 23, 2026, that GitLab’s private “Email work item to this project” addresses function as credentials that, if leaked, allow anyone who obtains them to push code to any branch the user can access—including main—and trigger CI/CD jobs running with that user’s permissions. The issue email addresses are frequently exposed in READMEs, contributing guides, and support pages, creating widespread credential leakage across public repositories.
How GitLab Issue Email Addresses Grant Unauthorized Code Push Access
GitLab provides each user with a private email address for creating work items and issues by sending email to the project. These addresses are designed for convenience—users can email issues directly to a project without logging into the GitLab web interface. However, the researcher found that anyone who obtains a user’s issue email address can use it to push code to any branch the user has write access to, effectively bypassing repository access controls.
The credential nature of these email addresses means they should be treated as secrets comparable to API tokens or SSH keys. But unlike API tokens, which developers generally recognize as sensitive and protect accordingly, issue email addresses are often treated as benign contact information and published in project documentation. This disconnect between the addresses’ actual permission scope and how developers perceive them creates a large-scale credential exposure problem.
CI/CD Job Triggering and Pipeline Compromise Risk
Beyond code pushing, leaked issue email addresses enable attackers to trigger CI/CD jobs that run with the user’s permissions. CI/CD pipelines often have access to secrets, deployment credentials, and production infrastructure, making pipeline compromise a high-value supply chain attack vector. An attacker who can trigger a pipeline using a leaked issue email address can potentially modify build scripts, inject malicious code into artifacts, or extract secrets from the pipeline environment.
The ability to trigger jobs compounds the risk of unauthorized code pushes. Even if an organization reviews all code changes before merging to main, an attacker who can both push code and trigger CI/CD jobs could bypass review processes by pushing to feature branches that automatically trigger pipeline jobs with broad permissions. Depending on the pipeline configuration, the attacker might never need code to reach main—they could achieve their objectives entirely within the CI/CD environment.
Issue Email Addresses Deliberately Exposed in Public Documentation
The researcher highlighted that issue email addresses are deliberately exposed in READMEs, contributing guides, and support pages to facilitate bug reporting and external contributions. Projects publish these addresses to make it easy for users to submit issues without creating GitLab accounts, but the exposure creates a security risk that many project maintainers do not recognize.
Once an issue email address appears in a public repository, it should be considered leaked. GitHub, GitLab, and other code hosting platforms are routinely scraped by researchers, security scanners, and attackers looking for exposed credentials. An issue email address in a README is as accessible as any other published credential, but unlike API tokens that trigger alerts when committed to public repositories, email addresses do not set off automated secret-detection tools.
GitLab User Response: Treat Issue Email Addresses as Secrets and Rotate if Exposed
GitLab users should immediately treat their issue email addresses as secrets equivalent to API tokens. These addresses should not be published in public documentation, included in repository files, or shared with untrusted parties. Projects that have already exposed issue email addresses in public repositories should rotate them by generating new addresses and removing the old ones from documentation.
GitLab provides the ability to rotate issue email addresses, but the process requires users to recognize they have been exposed and take action. The researcher’s disclosure aims to raise awareness that these addresses are not benign contact information but functional credentials that grant write access to repositories and CI/CD pipelines.
Organizations using GitLab should audit public repositories for exposed issue email addresses and establish policies prohibiting their inclusion in documentation. Alternative approaches for external bug reporting—such as dedicated issue submission forms, public email aliases that do not grant repository access, or security contact pages that collect reports without granting code-push capabilities—can achieve the same user-facing convenience without exposing credential-equivalent email addresses.
Redesign Calls and the Credential-by-Design Risk in Developer Tools
The researcher called for GitLab to redesign the issue email feature to eliminate its credential nature. The current design treats email addresses as both a convenience feature and an access control mechanism, a dual role that creates security risks because users do not recognize that publishing a convenience email address also publishes a credential.
Developer tools that embed access control into features designed for convenience—such as issue email addresses, webhook URLs with embedded tokens, or shareable links that grant write access—face similar risks. These features prioritize ease of use and frictionless collaboration, but they often do so by creating credentials that do not look like credentials, leading to widespread exposure when users treat them as non-sensitive information.
For GitLab, addressing the issue email credential problem likely requires either removing the code-push capability from these addresses or implementing additional authentication that prevents their use as standalone credentials. Until such a redesign occurs, the burden falls on users to recognize the credential nature of issue email addresses and protect them accordingly—a model that has already failed at scale, as evidenced by the widespread exposure the researcher documented.
