"Email work item to this project." GitLab shows each user this address behind that button — and, according to a report from Aikido Security, the private address it reveals is a credential that effectively lets anyone act as you inside projects you can touch.
The incoming‑email token GitLab issues and what it does
GitLab places a private email address in users' profiles that contains a persistent token tied to the account. The string in the middle of that address is the token, and GitLab's documentation says it does not expire. Aikido Security found that a single token is shared across a user's different project addresses and that the token applies to every project the account can open — public or private.
Mail sent to that address opens an issue in the target project, authored by the account owner. GitLab does not check who sent the email: "Any mailbox can write to the address, and GitLab acts on the message as if it came from you." In effect, possession of the address lets an attacker sign in as you to incoming‑email features and act with your permissions without ever touching your mailbox.
How Aikido converted issue email into commit access and CI jobs
Aikido demonstrated a simple, repeatable sequence that turns the issue address into a way to commit code and to run CI/CD jobs as the account owner:
- Change the address suffix from -issue to -merge-request so GitLab opens a merge request instead of an issue.
- Write a patch, put the target branch name in the email subject, attach the patch and send it.
- GitLab applies the attached patch to the named branch and creates the branch if it does not exist. The change lands as a commit authored by the account owner; if the attacker can push to the branch, that includes main.
- If the patch edits the project's .gitlab-ci.yml and the account's role allows it, GitLab will run the attacker's job as the account owner.
Aikido noted that the merge request itself cannot be pointed at a repository controlled by the attacker; the attached patch carries the actual code that lands in the target project.
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 scrambleConstraints, bypasses, and the limits of exposure
The token carries only the account's permissions, so how far a holder gets depends on the role: a leaked address for a Guest account is of little value, whereas one for a Maintainer can access protected branches and CI/CD secrets. Reaching a specific project requires knowing the project's path and numeric ID in addition to the token. Public projects publish both; private projects require a separate leak that names them. Aikido observed that project IDs are easy to guess.
The feature also bypasses two commonly used protections. GitLab's documentation states incoming email is not subject to IP restrictions, so an email can originate outside an IP allowlist. Aikido demonstrated this by locking a private project to a single IP that was not its own; GitLab's web controls blocked the team's browser and refused a git clone, yet the merge request email was accepted and the commit landed on main. Incoming email features also work without two‑factor authentication, even on instances that require it, according to GitLab's documentation.
Mitigations administrators and users can take now
Aikido and the public guidance built from its findings point to immediate, concrete steps:
- Reset your incoming‑email token from the personal access tokens page in your profile. The reset replaces every project address at once; any address you're actively using will stop working until you distribute the new one.
- Search your READMEs, contributing guides, and support pages for any published addresses. Aikido said it found about a dozen live addresses this way, most intentionally posted as bug‑report endpoints and a few in widely used open‑source projects.
- On self‑managed instances, an administrator can turn incoming email off for the entire instance. There is no per‑user switch to disable email‑based issue or merge‑request creation.
GitLab changed the text around the token after Aikido's report: the description now says the address can create issues and merge requests, and GitLab removed a line that had stated the token could not be used to access any other data. The underlying behavior — non‑expiring token, lack of sender verification, and absence of a per‑user off switch — has not changed.
What this means for Maintainers, Guests, and self‑managed administrators
Maintainers: A leaked incoming‑email token confers substantial risk. Because a Maintainer's token can push to protected branches and enable CI jobs that access secrets, maintainers should reset tokens immediately and audit any published email endpoints in project documentation.
Guests: A Guest account's leaked address is junior in impact, but still useful for reconnaissance and for rolling low‑privilege changes that might later be leveraged. Guests should also rotate tokens and check published contact points.
Self‑managed administrators: You can disable incoming email for the whole instance; there is no per‑user control. Administrators should evaluate whether the convenience of email‑based issues outweighs the risk of leaked tokens and consider instance‑wide disablement or tighter operational controls.
Aikido first reported the behavior through HackerOne in May 2026, where it was closed as intended behavior, then filed a confidential issue with GitLab in June. GitLab, as Aikido described, has characterized the address as "a token like any other" and has opened an issue to consider accepting these emails only from addresses verified on the account owner — but that change is under consideration, not in place. The Hacker News has reached out to GitLab and Aikido for comment.
For now, the practical choice is manual: rotate the token, remove public postings of the address, and decide whether your instance should keep incoming email enabled at all.
