A GitLab email token exposure flaw is allowing attackers to push code, open merge requests, and raid CI/CD secrets, and the entry point has been hiding in plain sight inside public READMEs and contributing guides the whole time. Researchers at application security company Aikido have published findings showing that a built-in GitLab feature, quietly misused, hands outsiders the ability to act as a project’s token owner with no password required.
What the GitLab email token actually does
GitLab includes a feature called ‘Email work item to this project’, which generates a private email address for each project. When an external sender fires a message to that address, GitLab parses it into a project issue or task, attributed to the account that owns the token. The address embeds a `glimt-` string that serves as the credential for the entire operation.
According to gblock.app, that `glimt-` token is tied to the whole account and never expires. There is no automatic rotation, no time-based invalidation, and no mechanism forcing a refresh unless the owner manually resets it. Once exposed, it stays exposed until someone acts.
The token also persists across all similar addresses generated for a given project. Resetting it is a manual step, one that most maintainers who have inadvertently published the address almost certainly have not taken.
The GitLab email token exposure attack path
The attack surface is wider than the feature’s name suggests. Aikido’s researchers found that changing the `-issue` suffix in the email address to `-merge-request` causes GitLab to open a merge request rather than file an issue. No additional authentication is needed. GitLab accepts the message as if it came from the token owner, regardless of who actually sent it.
Gblock.app’s analysis adds a further detail that sharpens the risk: the suffix swap allows the sender to attach `.patch` files, which GitLab then applies to a branch named in the subject line of the email. An attacker with the exposed address can, in effect, nominate a branch and push code changes to it, all sourced from an arbitrary external mailbox.
‘Any mailbox on the internet can send to that address, and GitLab processes the message as the token’s owner,’ the Aikido researchers state. Their tests also showed the attack bypasses IP address restrictions entirely, which removes one of the few mitigations that security-conscious teams might have assumed was in play.
The resulting level of access depends on the token owner’s permissions, but the potential list is serious: code changes, CI/CD pipeline runs, access to private repositories, and exposure of stored secrets. In public projects, the project path and ID needed to complete the attack are freely available. In private projects, the ID can be brute-forced, though the path would need to be leaked separately.
Aikido notes that, in principle, GitLab could add a layer of defence by verifying that the sending address matches the token owner’s email, but GitLab does not currently do this, though Aikido says GitLab is now considering it.
Dozens of live addresses found, popular projects affected
In a single afternoon, Aikido’s researchers found a dozen live incoming email addresses sitting in public READMEs, contributing guides, and support pages. The addresses had been placed there deliberately by maintainers wanting to collect bug reports by email, a reasonable instinct, executed in a way that GitLab’s own documentation warns against.
‘A few belonged to very popular open source projects,’ the researchers say. When popular open-source projects are involved, the supply-chain implications extend well beyond the individual maintainer: a compromised merge request reaching a widely-used package affects every downstream consumer.
GitLab itself warns in its documentation that these addresses are private and ‘generated just for you’, adding: ‘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.’ That warning has clearly not reached everyone who needed to read it.
Aikido reported the issue to GitLab via HackerOne in May. GitLab initially closed it as ‘intended behavior.’ A second notification in June prompted GitLab to update its UI to reference merge requests, remove what Aikido described as false statements about token data access, and document that incoming email bypasses IP restrictions.
For project maintainers, the immediate steps are straightforward: stop including these addresses in public documentation, and reset tokens for any project where the address has already appeared. The token never expires on its own, which means the clock on any past exposure is still running.
