GitLab's Incoming-Email Token Can Push Code as You

A researcher at Aikido Security says a private email address GitLab gives every user to file issues by email doubles as a credential that never expires, letting anyone who obtains it push a patch and run CI/CD jobs under that person's identity.

In a post published Wednesday, Aikido's Joe Leon says GitLab first told him in May 2026, through a HackerOne submission, that the design was intended behavior rather than a vulnerability. The feature itself is meant as a convenience: it lets a user open an issue or reply to one from a mail client, without logging into GitLab's web interface at all.

How the address turns into a patch

Every GitLab project shows a button labeled "Email work item to this project," Leon writes, producing an address in the form incoming+<project-id>-glimt-<token>-issue@incoming.gitlab.com. Mail sent to it opens an issue in that project, authored by whoever the token belongs to. Change -issue to -merge-request, attach a Git patch, and name a source branch in the subject line, and GitLab applies the patch under that same identity, to any branch the account can push to, including a protected branch such as main. If the patch edits .gitlab-ci.yml and the account's role allows it, the CI/CD job defined in that file runs as the account.

Why the token is different from an ordinary one

"It's a long-lived token tied to your account, and it never expires," Leon writes. He says GitLab's position, that this is a token like any other, "sidesteps what makes this one different": the same token works across every project the account can open, public or private, and it bypasses IP allowlists that would normally block ordinary git or HTTP access. How far an attacker gets still depends on the account's role. A leaked address tied to a Guest account is close to useless; one tied to a Maintainer can reach protected branches and CI/CD secrets.

Where the disclosure stands

Date	Event
May 2026	Leon reports the issue via HackerOne; GitLab closes it as intended behavior
June 2026	Leon files a confidential issue directly with GitLab
Sept. 23, 2026	Aikido publishes the finding

GitLab has since merged a documentation and interface update clarifying what the token can do, and opened a work item considering whether to require a message's sender address to match the account before honoring it. Neither change is a fix on its own: the token still does not expire, and GitLab has not committed to a date for the verification work.

GitLab patched a path-traversal bug that attackers began probing within a day of its Sept. 10 fix; the pattern in both cases is the same, a credential or access path that works exactly as designed until someone notices how far it actually reaches. A three-year-old GitHub admin token sitting exposed in a different company's public container registry made the same point about long-lived credentials.

GitLab has not said how many incoming-email addresses were issued before the non-expiring design was documented, or how it would notify a user if theirs leaked.