Aikido's discovery
Researchers at application security company Aikido found multiple private GitLab incoming email addresses exposed in public README files, contributing guides, and support pages. In one afternoon the team discovered a dozen live addresses; the researchers say the addresses were deliberately included in public documentation to let external users send bug reports to maintainers. Aikido reported the problem to GitLab through HackerOne in May; after GitLab closed that report as "intended behavior," a second notification in June prompted further action.
How GitLab's "Email work item to this project" works
The email addresses are created by a built-in GitLab feature called "Email work item to this project." Each address is generated automatically and embeds a long-lived token — a string beginning with "glimt-" — that acts as a credential allowing the recipient to create work items via email. When an external mail client sends a message to one of these addresses, GitLab parses it into a project issue or task.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleImmediate risks: code, secrets, and supply-chain exposure
Aikido warns that an attacker who obtains one of these addresses could perform a range of actions depending on the tied account's permissions. The researchers explicitly say such an attacker could push code to protected branches of private repositories, steal source code, collect secrets from CI/CD variables, or access confidential issues. They also demonstrated that an attacker who knows the address can change the "-issue" suffix to "-merge-request" and GitLab will open a merge request on the project.
The researchers further found that incoming email processing bypasses IP address restrictions, saying the attack would skirt those controls. Aikido notes that beyond the permission envelope — which they say cannot be bypassed — an attacker also needs a project's path and ID. For public projects those details are publicly available; for private projects Aikido says the project ID can be brute-forced while the project path would need to be leaked.
GitLab's documentation changes and the vendor response
GitLab's documentation already warns that these addresses are private and "generated just for you." The documentation tells users: "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." After Aikido's follow-up in June, GitLab updated its user interface to mention merge requests, removed false statements about token data access, and documented that incoming email bypasses IP restrictions. Aikido also reports that GitLab is "now considering" adding a check that the sending address matches the token owner's email — a step Aikido says would "add a layer of defense" but which GitLab has not yet implemented.
What this means for project maintainers, enterprise security teams, and attackers
- Project maintainers: Stop voluntarily publishing these private addresses in public READMEs or support pages and reset tokens for projects where the addresses were exposed, Aikido advises.
- Enterprise security teams and open-source consumers: Aikido flags a supply-chain risk where popular open source projects can expose tokens in public documentation; organizations that consume those projects should be aware that a leaked address could enable code or CI/CD-level manipulation tied to the token owner's permissions.
- Attackers and threat actors: With an exposed address and the project path/ID, attackers can open merge requests (by switching the suffix), create issues, and potentially initiate actions that exploit the account permissions — and they can do so from any mailbox on the internet because GitLab processes messages as the token's owner.
The record in Aikido's report is specific: these tokens persist across similar addresses for a project, can be switched from issue to merge-request processing, and are processed without checking sender IPs. GitLab has updated documentation and UI text after the alerts and is reportedly considering sender-address validation, but maintainers remain the first line of defense: stop publishing the addresses publicly and reset any leaked tokens.
Source: Exposed GitLab project email addresses let attackers push code — BleepingComputer
