Aikido found that GitLab’s per-account issue email address can be used by anyone who has it to act as that user across their projects. The token in the address does not expire, and GitLab reuses it for the user’s different projects, so one leaked address can reach more than the one project it was meant to file issues for.
GitLab does not verify the sender’s mailbox. Mail sent to the address can become an issue, a merge request, a commit on a chosen branch, and, if the project settings allow it, a CI/CD job run as the victim. In other words, the address itself behaves like a reusable credential, and the blast radius follows the user’s GitLab role.
If a team uses email-to-issue or email-to-merge workflows, the trust boundary is the address token, not mailbox access. That means a leak can expose code paths and automation privileges across every project the account can reach, including protected branches and CI secrets for higher-privilege users.