# GitLab's incoming email address is a non-expiring token that commits code and runs CI as you

Source: https://startwithidentity.com/blog/2026-09-23-gitlab-incoming-email-token-lets-anyone-commit-and-run-ci-as-you/
Last updated: 2026-09-23
License: content by Start with Identity. Cite the source URL.

---

Aikido Security disclosed on September 23 that the private email address GitLab gives each user for creating issues by email works as a credential. Changing the address suffix from `-issue` to `-merge-request` lets anyone who knows it email a patch that GitLab commits in the user's name, to any branch that user can push to, including main, and start CI/CD jobs that run as them. The token behind the address does not expire, covers every project the account can open, and bypasses IP restrictions and two-factor authentication, because GitLab does not check who sent the email. It affects GitLab.com and self-managed instances with incoming email configured. Aikido reported it through HackerOne in May; GitLab closed it as intended behavior, updated its documentation, and opened an issue to consider sender verification. Users can reset the token from their access tokens page; administrators can disable incoming email instance-wide.

## Why it matters

Most token inventories would miss this one because it does not look like a token. It looks like an email address, which is exactly why people paste it into READMEs, support tickets and wiki pages to make "email us to open an issue" work. It is a bearer credential with write access to every project the user can reach, no expiry, and no second factor, so it belongs in the same inventory and rotation process as personal access tokens and deploy keys. See [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/).

Two checks this week. Search your public documentation and ticket systems for GitLab incoming email addresses, and reset the token for any account whose address has ever been shared. Then look at branch protection: requiring an approved merge request limits which branches a mailed patch can land on, but it does nothing about the CI jobs that run as the user, which is where secrets live. This is the same shape as [coding agents reaching CI secrets through a GitHub issue](https://startwithidentity.com/blog/2026-08-07-coding-agent-flaws-let-a-github-issue-reach-ci-secrets/): an input channel nobody classified as an authentication path. See [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/).

Source: [The Hacker News](https://thehackernews.com/2026/09/a-leaked-gitlab-issue-email-address.html)