FHN 
GitLab’s “Email work item to this project” feature could create a security risk when its private email address becomes exposed, according to research from Aikido Security researcher Joe Leon.
The email address contains a long-lived incoming-email token. GitLab documentation says this token must remain private because anyone who has it can perform actions as the token owner, including creating issues and merge requests.
The problem becomes more serious because the feature can also be used to send code changes into a repository.
A Private Email Address Can Trigger Code Changes
Aikido found that email addresses created for different projects can contain the same account-level token.
An attacker who obtains the address can reportedly change the email format from an issue address to a merge-request address and include a Git patch. By specifying a source branch in the email subject, GitLab can apply the patch using the permissions of the token owner.
This means the feature is not limited to creating unwanted issues.
For example, an attacker could modify a project’s .gitlab-ci.yml file. If the change triggers a CI/CD pipeline, attacker-controlled commands could potentially run within the victim’s project.
Depending on the user’s permissions and pipeline setup, this could expose source code, CI/CD variables, job tokens, or other sensitive information.
Network Restrictions May Not Stop It
The research also found that GitLab’s incoming email workflow can bypass assumptions about IP-based restrictions.
Aikido reported testing a private project that allowed access only from a specific IP address. While browser access and Git cloning were blocked, the emailed patch was still accepted and resulted in a commit to the main branch.
GitLab now documents that incoming email is not covered by IP restrictions, meaning an IP allowlist should not be considered a complete security control for this feature.
An attacker does not necessarily need to spoof the sender either, because GitLab does not currently require the email to come from an address verified on the token owner’s account.
What GitLab Users Should Check
GitLab has treated the behavior as part of the feature’s design rather than a traditional vulnerability. The company has nevertheless updated its interface and documentation to better explain the risks and the capabilities of incoming email addresses.
Organizations should search repositories, documentation, tickets, logs, and public pages for exposed glimt- email addresses and older incoming-mail token formats.
If an address has been exposed, the associated incoming email token should be reset, which invalidates the related project email addresses.
Security teams should also review:
- User permissions
- Protected branch settings
- CI/CD pipelines
- CI/CD variables
- Recent commits
- Audit events
The main takeaway is simple: GitLab project email addresses containing incoming-mail tokens should be treated like credentials and kept secret.
About the Author
