Exposed GitLab project email addresses let attackers push code

Recorded: Sept. 24, 2026, 6:02 p.m.

Original

News

Featured
Latest

ShinyHunters claims FBI hack, data theft in PeopleSoft zero-day breach

New Windows Defender zero-day blocks Microsoft antivirus updates

EvilTokens PhaaS disrupted after compromising 12,000 Microsoft accounts

Check Point warns of Management Server zero-day exploited in attacks

Exposed GitLab project email addresses let attackers push code

FedRAMP VDR & VER: Daily Scans Are Only the Beginning

Hackers now exploit critical Roundcube flaw in code injection attacks

Windows 11 KB5124010 update released with 46 changes and fixes

Tutorials

Latest
Popular

How to access the Dark Web using the Tor Browser

How to enable Kernel-mode Hardware-enforced Stack Protection in Windows 11

How to use the Windows Registry Editor

How to backup and restore the Windows Registry

How to start Windows in Safe Mode

How to remove a Trojan, Virus, Worm, or other Malware

How to show hidden files in Windows 7

How to see hidden files in Windows

Webinars
Downloads

Latest
Most Downloaded

Qualys BrowserCheck

STOPDecrypter

AuroraDecrypter

FilesLockerDecrypter

AdwCleaner

ComboFix

RKill

Junkware Removal Tool

Deals

Categories

eLearning

IT Certification Courses

Gear + Gadgets

Security

VPNs

Popular

Best VPNs

How to change IP address

Access the dark web safely

Best VPN for YouTube

Forums
More

Virus Removal Guides
Startup Database
Uninstall Database
Glossary
Send us a Tip!
Welcome Guide

HomeNewsSecurityExposed GitLab project email addresses let attackers push code

Exposed GitLab project email addresses let attackers push code

By Bill Toulas

September 24, 2026
01:47 PM
0

Private GitLab email addresses that allow developers to push issues or tasks to a project are being deliberately exposed in READMEs, contributing guides, and support pages used to collect bug reports.
The addresses are part of a built-in GitLab feature called "Email work item to this project" and contain a long-lived token tied to the developer’s account.
These addresses are generated automatically and contain a string that serves as a credential for creating work items via email. When an external client sends a message to one of them, GitLab parses it into a project issue or task.
Researchers at application security company Aikido found multiple private GitLab addresses exposed in public documentation and are warning about the associated risk.
An attacker could use them to compromise GitLab accounts in attacks that push code to protected branches of private repositories, steal source code, collect secrets from CI/CD variables, or access confidential issues.
Each of these private GitLab address embed a ‘glimt-’ string that acts as a credential for accessing the project, which persists across all similar addresses generated for the respective project.
"Change the -issue suffix in the email address to -merge-request, and GitLab will open a merge request," Aikido says.

Modifying the email addressSource: Aikido
An attacker who knows that address or can retrieve it could change the ‘-issue’ suffix to ‘merge-request,’ and GitLab would accept it, opening a merge request on the project.
“In principle, checking the sending address matches the token owner's email would add a layer of defense, but GitLab doesn't do this (though they are now considering it),” the researchers say.
“Any mailbox on the internet can send to that address, and GitLab processes the message as the token's owner.”
Additionally, Aikido's tests showed that the attack would bypass IP address restrictions as well.
The resulting level of access depends on the user’s account permissions and may allow code changes, CI/CD runs, access to private repositories, secrets, etc.
The researchers note that, besides the permission restriction, which cannot be bypassed, an attacker also needs the target project’s path and ID.
In public projects, this info is publicly available, while in private projects, the ID can be brute-forced, but the path would need to be leaked.
GitLab warns in its documentation about the security implications of exposing these addresses, saying that they are private and "generated just for you."
"Keep it to yourself, because anyone who knows it can create issues or merge requests as if they were you. If you suspect this private email address was leaked, reset the token immediately," GitLab warns.
Exposed private email addresses
In one afternoon, Aikido researchers found a dozen live GitLab incoming email addresses in public READMEs, contributing guides, and support pages.
The researchers say that these addresses were deliberately included in public documentation to send bug reports to maintainers.
In many cases, the exposure affected popular open-source projects, creating supply-chain risks for large user bases. "A few belonged to very popular open source projects," the researchers say.
Aikido says it reported the issue to GitLab through HackerOne in May, but GitLab closed it as “intended behavior.”
The company followed up with a second notification in June, prompting GitLab to update its UI to mention merge requests, remove false statements about token data access, and document that incoming email bypasses IP restrictions.
Project maintainers should stop voluntarily exposing that info in public documentation and reset tokens for projects they exposed this way in the past.

Build your security blueprint for AI-powered attacks

Join Mikko Hyppönen and security leaders from the NFL, CHANEL, and Atlassian for a two-hour digital summit on what AI-speed attacks change, what defenders should stop doing, and how to validate, decide, fix, and re-validate at machine speed.
Save your seat

Related Articles:
GitHub, PyPI add time-based defenses against supply chain attacksHackers now exploit critical Roundcube flaw in code injection attacksPlaceholder domain used in dev docs now serves ClickFix attacksBrevo supply-chain attack injected ClickFix scripts on customer sitesMalcious Admin Menu Editor Pro plugin backdoors 1,500 WordPress sites

Developer
Email
GitLab
Security
Supply Chain

Bill Toulas
Bill Toulas is a tech writer and infosec news reporter with over a decade of experience working on various online publications, covering open-source, Linux, malware, data breach incidents, and hacks.

Popular Stories

ShinyHunters claims FBI hack, data theft in PeopleSoft zero-day breach

Microsoft reminds admins to migrate Entra ID users to passkeys

New Windows Defender zero-day blocks Microsoft antivirus updates

Sponsor Posts

AI is a data-breach time bomb: Read the new report

Overdue a password health-check? Audit your Active Directory for free

Build cyber resilience with Wazuh: The open-source SIEM & XDR for proactive protection

Daily detection, monthly validation, 12-hour clocks. Are you VDR & VER ready?

Automate Onboarding and Access Reviews with No-Code IGA: See how it works

Main Sections

News
Webinars
VPN Buyer Guides
SysAdmin Software Guides
Downloads
Virus Removal Guides
Tutorials
Startup Database
Uninstall Database
Glossary

Community

Forums
Forum Rules
Chat

Useful Resources

Welcome Guide
Sitemap

Company

About BleepingComputer
Contact Us
Send us a Tip!
Advertising
Write for BleepingComputer
Social & Feeds
Changelog

Username

Password

Remember Me

Not a member yet? Register Now

Reporter

Help us understand the problem. What is going on with this comment?

Spam

Abusive or Harmful

Inappropriate content

Strong language

Other

Read our posting guidelinese to learn what content is prohibited.

Submitting...
SUBMIT

Private GitLab email addresses, which are intended for notifying developers about work items, are being deliberately exposed in public documentation, including READMEs, contributing guides, and support pages. These addresses are generated through a built-in GitLab feature called "Email work item to this project" and are associated with long-lived tokens tied to the developer's account. The addresses contain a specific string, such as ‘glimt-’, which functions as a credential for interacting with the project.

Researchers from the application security company Aikido discovered multiple instances of these private GitLab addresses publicly exposed, which poses significant security risks. An attacker who obtains these addresses can exploit them to compromise GitLab accounts. Specifically, by modifying the standard email address suffix from ‘-issue’ to ‘-merge-request,’ the attacker can instruct GitLab to open a merge request on the project. This mechanism allows the attacker to effectively impersonate the token owner, enabling actions that bypass typical security controls.

The researchers demonstrated that this method allows an attacker to bypass IP address restrictions. While GitLab does not inherently check if the sending address matches the token owner’s email, and the researchers note that GitLab is currently considering adding this defense, any mailbox on the internet can send messages to that address, and GitLab processes the communication as originating from the token owner. Consequently, the resulting level of access depends on the permissions granted to the user account, potentially allowing the attacker to execute code changes, initiate CI/CD runs, access private repositories, collect secrets from CI/CD variables, or view confidential issues. Furthermore, to fully exploit this vulnerability, an attacker also needs the target project’s path and ID, which are often publicly available in public projects, although they can potentially be brute-forced in private projects if the path is leaked.

These exposures create substantial supply-chain risks, particularly for large user bases in popular open-source projects. GitLab warns that these email addresses are private and generated specifically for the user, emphasizing that anyone with knowledge of them can execute actions as if they were the legitimate owner. Therefore, GitLab advises that if any private email address is suspected of leaking, the associated tokens should be immediately reset. Project maintainers are strongly advised to cease voluntarily exposing this information in public documentation and to reset project tokens where such information has been previously exposed.