GitLab incoming-email token (glimt-): Aikido shows leaked issue-by-email address can push MRs / CI across projects
Aikido Security (Joe Leon, 23 September 2026) demonstrates that GitLab's "Email work item to this project" / incoming-email address embeds a long-lived account-level glimt- token that does not expire. Anyone holding the address can create issues — and, by changing the -issue suffix to -merge-request and attaching a git patch, open merge requests or push commits under the victim's identity, including CI/CD via .gitlab-ci.yml when role/permissions allow (Maintainer may reach protected branches). Token is account-scoped (same secret across projects), not project-scoped as the UI implies; email path also bypassed IP allow-lists in Aikido's test (browser/git clone blocked, email accepted). GitLab docs frame the Incoming email token as issue-creation only. No CVE assigned in the research. Mitigations: treat issue-by-email addresses as secrets; rotate/revoke incoming email token in User settings; avoid publishing addresses; review unexpected MRs/pipelines authored as users who use email work items. Primary: Aikido research; wire: Cyber Security News 23 Sep 2026.
- Product
- GitLab CE/EE — Incoming email / Email work item to this project (glimt- token)
- Versions
- Feature abuse of long-lived incoming-email token (no CVE / no version cutoff in research). Rotate token; stop publishing addresses.
- Exploited in Australia?
- unknown
- Patch to
- Revoke/rotate Incoming email token (User settings); treat issue-by-email addresses as credentials; hunt unexpected MRs/CI by users who share those addresses
Primary: Aikido — Send GitLab an email, push to main (23 Sep 2026) · Cyber Security News — GitLab email feature (23 Sep 2026)