Vulnerabilities · 3h ago
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.
2 sources covering this story
GitLab Email Addresses Can Be Weaponized for Supply Chain Attacks
Incoming email addresses automatically assigned to each user on the platform contain highly privileged access tokens that attackers can use.
A Leaked GitLab Issue Email Address Lets Anyone Push Code and Run CI Jobs as You
GitLab’s non-expiring incoming email token can let a holder commit code with a user’s permissions and trigger CI/CD jobs.
Part of the PlainSec briefing for 2026-09-23