Public READMEs are leaking GitLab email tokens that let any sender act as the account owner
Aikido found a dozen live GitLab 'email work item' addresses in public docs, each carrying a long-lived token that lets any mailbox act as its owner. GitLab calls it intended behavior, so maintainers must pull the address and reset the token.
The Watch · Security desk
What happened
- Aikido researchers found a dozen live GitLab incoming-email addresses in public READMEs, contributing guides and support pages in a single afternoon.
- Maintainers had put the addresses in public documentation on purpose, as a way to collect bug reports.
- The addresses come from GitLab's 'Email work item to this project' feature, and each carries a long-lived token tied to the developer's account.
- Swapping the address's -issue suffix for -merge-request makes GitLab open a merge request on the project instead of an issue.
- Aikido reported the problem to GitLab through HackerOne in May, and GitLab closed the report as intended behavior.
Why it matters
- What it limits constraint IP allowlists do not cover this path. Until GitLab checks who sent the message, keeping the address secret is the only control on a leaked token.
- Who's exposed exposure When the address belongs to a popular open-source project, a merge request filed under a maintainer's identity puts that project's downstream users within reach, the supply-chain risk the report describes.
- Who has to decide decision GitLab treats the behavior as intended. Maintainers who use the address as a public bug inbox have to move bug intake to another channel themselves.
- What it costs cost Cleanup covers past exposure too. Because the token is long-lived, any project that ever published the address needs a reset, even if the address has since been taken down.
Next story · Security · 4d ago
GitLab patches a maximum-severity code execution flaw in its CI/CD regex compilerConfirmed7 publishers
The attack needs one leaked address and one outbound email. "Any mailbox on the internet can send to that address, and GitLab processes the message as the token's owner," the Aikido researchers said [7]. Aikido's tests showed the route also gets past IP address restrictions [8]. "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 said [9].
The sender gets whatever the token owner's account can do. Depending on those permissions, that can mean code changes, CI/CD runs, private repositories and secrets [10]. BleepingComputer, reporting the research, says it can extend to pushing code to protected branches of private repositories, stealing source code, collecting secrets from CI/CD variables and reading confidential issues [11]. Aikido says the permission limit itself cannot be bypassed [12].
Private repositories take more than the leaked address. The attacker also needs the target project's path and ID [13]. On a public project both are already public, so a live address in a README works at once against the project that published it [3] [14]. On a private project the ID can be brute-forced, but the path has to leak [14].
The credential is a string beginning 'glimt-' embedded in each address, and it persists across all similar addresses generated for the project [15]. A secret scanner can match that string in project documentation. The report does not identify the affected projects or describe any use of the addresses in an attack [4].
GitLab's documentation calls the address private and "generated just for you" [16]. "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," the documentation says [17].
After Aikido's second notification in June, GitLab updated its UI to mention merge requests, removed false statements about token data access and documented that incoming email bypasses IP restrictions [18].
What to watch
- Whether GitLab adds the check that the sending address matches the token owner's email, which Aikido says GitLab is now considering.
- Whether Aikido or the affected maintainers identify the popular open-source projects whose addresses were exposed and confirm their tokens were reset.
- Any report of a merge request or issue opened by an outsider through a leaked incoming-email address.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence68
- Adoption28
- Hype gap+10
- Incentives52
- Confidence60
Perspective Coverage
3 publishers- Builder
- Builder 43%
- Operator
- Operator 52%
- Investor
- Investor 5%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
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.
- [2]
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.
- [3]
In one afternoon, Aikido researchers found a dozen live GitLab incoming email addresses in public READMEs, contributing guides and support pages.
- [4]
"A few belonged to very popular open source projects," the researchers say.
- [5]
"Change the -issue suffix in the email address to -merge-request, and GitLab will open a merge request," Aikido says.
- [6]
Aikido reported the issue to GitLab through HackerOne in May, but GitLab closed it as 'intended behavior.'
- [7]
"Any mailbox on the internet can send to that address, and GitLab processes the message as the token's owner."
- [8]
Aikido's tests showed that the attack would bypass IP address restrictions.
- [9]
"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.
- [10]
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.
- [11]
An attacker could use the addresses 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.
- [12]
Besides the permission restriction, which cannot be bypassed, an attacker also needs the target project's path and ID.
- [13]
An attacker also needs the target project's path and ID.
- [14]
In public projects the path and ID are publicly available; in private projects the ID can be brute-forced, but the path would need to be leaked.
- [15]
Each of these private GitLab addresses embeds a 'glimt-' string that acts as a credential for accessing the project, which persists across all similar addresses generated for the respective project.
- [16]
GitLab warns in its documentation that these addresses are private and "generated just for you."
- [17]
"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."
- [18]
Aikido 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.
- [19]
Project maintainers should stop voluntarily exposing the addresses in public documentation and reset tokens for projects they exposed this way in the past.
- [20]
In many cases, the exposure affected popular open-source projects, creating supply-chain risks for large user bases.
Sources
2 independent publishers whose own reporting we read for this story.
- bleepingcomputer.comExposed GitLab project email addresses let attackers push code
1 article · September 24, 2026
- scworld.comPrivate GitLab email addresses exposed in public documentation
1 article · September 24, 2026
- thehackernews.comA Leaked GitLab Issue Email Address Lets Anyone Push Code and Run CI Jobs as You
2 articles · September 24, 2026