Leaked GitLab Email Address Could Let Attackers Push Code and Run Jobs as You
GitLab gives every user a private email address for filing issues by sending mail, accessible via an 'Email work item to this project' button. Researchers at Aikido Security discovered this address is far more powerful than it looks: the token embedded in it doesn't expire, applies across all of a user's projects (public or private), and isn't checked for sender authenticity. Anyone who obtains the address can act as that user, opening issues, and, using GitLab's merge request by email feature, pushing committed code straight to protected branches such as main.
The risk scales with the account's permissions. A leaked address tied to a low-privilege Guest account is largely harmless, but one belonging to a Maintainer can reach protected branches and CI/CD secrets, effectively letting an attacker run pipeline jobs as that user. Reaching a specific project also requires its path and numeric ID, information that is public for open projects but must be separately obtained for private ones. Aikido also found that email-based actions bypass IP allowlist restrictions entirely, demonstrating that a locked-down private project could still be modified via a malicious email from an unauthorised IP.
This flaw means that email addresses businesses may assume are low-risk internal identifiers should actually be treated as sensitive credentials, since anyone who obtains one can impersonate the associated user's GitLab permissions.