A project email address looks like something you can paste into a README or support guide. In GitLab, the private address for creating work items by email is different: it contains a non-expiring token tied to the user. GitLab says anyone with that token can create issues and merge requests as that user. If one of these addresses has been published or copied into a ticket, treat it as an exposed credential and reset it.
On September 23, Aikido researcher Joe Leon published tests showing why the distinction matters. In projects the researchers controlled, possession of an incoming email address enabled actions beyond submitting a work item, including a code change and a CI/CD run when the token owner had sufficient permissions. Dark Reading independently interviewed Leon and reported on the findings. The public evidence demonstrates a risky capability; it does not establish that an attacker has used it against a real organization.
What GitLab confirms
GitLab's token documentation says the incoming email token does not expire and is included in a user's project-specific email addresses. It explicitly advises keeping the token secret and resetting it immediately if exposure is suspected. GitLab also says incoming email is not subject to group IP restrictions, so an IP allowlist should not be counted on to block this route.
The research adds a narrower, important observation: the token inside addresses shown for different projects belongs to the same account. What someone can accomplish still depends on that user's GitLab role and the target project. The researchers tested higher-impact actions with their own projects; the result is not a claim that every leaked address grants repository write access.
Check whether an address escaped
- Find where it was shared. Search repositories, documentation, issue trackers, chat history, build logs and support templates for GitLab incoming-email addresses. Review public material first, but include internal systems that broad groups or contractors can read. Do not paste a live address into a new search ticket or incident report.
- Identify its owner and reach. Determine whose account generated the address, their role, and which projects and CI/CD resources that role can affect. Keep the inventory to location, owner and exposure status; store the actual address only where responders need it.
- Reset exposed tokens at GitLab. GitLab's documented path is avatar → Edit profile → Access → Personal access tokens → Incoming email token → reset this token. Because the token is user-scoped, check every workflow that uses that person's incoming addresses and replace the old addresses after reset.
- Review activity proportionately. If the address was public or widely accessible, examine relevant issue and merge-request creation, commits and pipeline runs for unexpected changes. Preserve evidence and assess any CI/CD credentials those jobs could access. Exposure warrants a review; it does not by itself prove a compromise.
- Fix the sharing pattern. Remove live addresses from public guides and templates. If a team needs an email intake route, document its owner, audience and reset procedure, and review whether that account has more GitLab permissions than the workflow requires.
Where a short-lived handoff helps
An incoming email address that carries a token should move like a credential when a colleague or integration owner genuinely needs it. Verify the recipient through an established route, share the value only with that person, and avoid leaving a permanent copy in a chat thread or ticket. A short-lived Secretus transfer can help with that handoff. It does not shorten GitLab's token lifetime or undo an earlier leak: if the address was exposed, reset the token in GitLab and update dependent workflows.
Aikido says it found publicly posted live addresses in a limited search. That is a warning about the common assumption that an email address is safe to publish, not a measure of victims. No public source here establishes malicious exploitation, a number of compromised accounts, or stolen CI/CD secrets from this route.