GitLab email-to-issue feature exposes account-wide access via embedded token
GitLab's feature that lets users create issues by email embeds a long-lived personal access token in the address. Aikido Security found anyone with the address can push code and run CI/CD jobs across projects the account can access, bypassing IP restrictions. GitLab says the behavior is intended, not a vulnerability, but a researcher argues it should verify the sender's email address.
Aikido Security found that GitLab’s email-to-issue address carries a reusable credential prefixed with “glimt-.” Each project receives a distinct address, but the embedded token is identical across the account, so one exposed address can affect every project that account can access. The address follows a pattern containing project ID and token, such as incoming+project-id-glimt-...-issue@incoming.gitlab.com.
The token can create issues and merge requests. Changing the address suffix may make GitLab open a merge request, letting an attacker submit code changes that run in CI/CD. IP restrictions do not apply to email. The feature is on by default for GitLab.com accounts and cannot be turned off; self-hosted instances may enable it. GitLab calls the behavior intended, while Aikido urges sender-email verification.
Developers, teams, and organizations using GitLab could be affected if these secret addresses leak. Anyone obtaining one may act within the linked account’s permissions, potentially altering code or CI/CD pipelines. That may create downstream supply-chain concerns for users of affected projects. The dispute may also prompt platform operators and security teams to reconsider how convenience features embed long-lived credentials. Organizations may need to treat such addresses as sensitive secrets and review account permissions.