GitLab email tokens in READMEs can let attackers push code

Private GitLab email addresses, a built-in feature meant to let developers create issues or tasks by email, have been found exposed in public documentation on numerous projects, according to BleepingComputer's September 24, 2026 report on research from application security company Aikido. The addresses are part of a GitLab feature called "Email work item to this project" and contain a long-lived token tied to the developer's account.

The feature generates these private addresses automatically. Each address contains a secret string that acts like a password, and when an external client sends an email to one of them, GitLab parses the message into a project issue or task. Aikido found multiple private addresses in public READMEs, contributing guides, and support pages, and the researchers warn that the associated risk is serious. An attacker who knows such an address can use it to compromise GitLab accounts in ways that push code to protected branches of private repositories, steal source code, collect secrets from CI/CD variables, or access confidential issues.

Aikido's analysis shows that each private address embeds a "glimt-" string that acts as a credential for accessing the project. The same credential persists across all similar addresses generated for that project. According to the researchers, changing the "-issue" suffix in the email address to "-merge-request" causes GitLab to open a merge request. In principle, checking that the sending address matches the token owner's email would add a layer of defense, but GitLab does not currently do that, though the company is now considering it. The researchers also state that any mailbox on the internet can send to that address, and GitLab processes the message as the token's owner. Aikido's tests showed that the attack bypasses IP address restrictions as well.

The level of access depends on the permissions of the account that owns the token. An attacker could use it to push code to protected branches, run CI/CD jobs, access private repositories, or obtain secrets from stored variables. CI/CD variables are settings used by automated build, test, and deployment pipelines that often contain passwords and other secrets. Aikido notes that, besides the permission restriction, which cannot be bypassed, an attacker also needs the target project's path and ID. In public projects this information is publicly available, while in private projects the ID can be brute-forced, meaning repeatedly guessed until the right one is found, but the path would need to be leaked.

GitLab's documentation warns that these addresses are private and "generated just for you." It tells users to keep the address to themselves because anyone who knows it can create issues or merge requests as if they were the owner, and to reset the token immediately if they suspect it leaked. In one afternoon, Aikido researchers found a dozen live GitLab incoming email addresses in public READMEs, contributing guides, and support pages. The researchers say the addresses were deliberately included in public documentation to collect bug reports from users. 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, Aikido said. Aikido reported the issue to GitLab through HackerOne, a platform for reporting security vulnerabilities, in May 2026, but GitLab closed it as intended behavior. A second notification in June 2026 prompted GitLab to update its user interface 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 information in public documentation and reset tokens for projects where they exposed them in the past.

For website owners and IT teams that maintain public code or documentation, the practical takeaway is to treat any project email address as a credential, not a public contact. AEU-I, AEU Group's security-first IT and infrastructure consulting service, can help organizations review their public-facing code and documentation for exposed project tokens before an attacker finds them. The best defense is to remove the addresses from public pages and reset any tokens that have already appeared there.