Your GitLab issue-email address can push code — rotate it today

By George Bailey   Published: 09/25/26   4 min read
Cybersecurity

The private “email an issue to this project” address in GitLab looks like a mailbox. It’s really a key: anyone who has it can push code to branches you can push to, main included, and run CI jobs as you.

Some teams publish that address in their README on purpose.

It’s formatted like an email address. It behaves like a password.

What happened

On September 23, Aikido Security researcher Joe Leon published research on the incoming email address GitLab gives each user (“Email work item to this project”). The address embeds a long-lived glimt- token that never expires. The same token appears in every project address for that user, so it works account-wide across public and private projects.

GitLab doesn’t verify the sender. Swap the -issue suffix for -merge-request, attach a git .patch, and GitLab commits to the named branch in your name. If the patch changes .gitlab-ci.yml and your role allows it, GitLab runs the job.

Aikido showed it pushing to a protected branch in a private repo behind an IP allowlist, reading CI/CD variables, and reaching confidential issues. It found about a dozen live addresses in public READMEs and contributing guides.

Why it matters

This is a supply-chain path hiding in plain sight. Email bypasses IP restrictions, you can’t turn the feature off, and GitLab closed the HackerOne report as intended behavior. GitLab updated its UI text and documented that incoming email isn’t subject to IP restrictions, but there’s no bulk revoke.

The victim’s role bounds the damage: a leaked Maintainer address is serious, a Guest address much less so. It’s the third source-control access story on our desk this month, after GitLab’s unauthenticated file-read bug and the departed employee who kept GitHub access at CrowdSec.

What to do first

  1. Rotate your token. User settings › Access tokens › reset Incoming email token. This invalidates all of your project addresses. Start with Maintainers and Owners.
  2. Pull published addresses. Search READMEs, CONTRIBUTING files, wikis, and support pages for incoming+ / glimt- addresses and remove them.
  3. Scan for it like any secret. Add the pattern to your secrets scanning rules.
  4. Stop treating GitLab IP allowlists as a hard boundary for code changes.
  5. If an address was public: review recent commits and merge requests created by email, pipeline runs, and CI/CD variable access.

Forward this

If you’re a GitLab Maintainer or Owner: reset your Incoming email token today (User settings › Access tokens) and pull any incoming+… address out of public docs.

Details

Hunt / verify

Slack paste: GitLab Maintainers/Owners: reset Incoming email token (User settings › Access tokens); remove incoming+ addresses from public docs; add glimt- to secret scanning.

FAQ

Is there a CVE or patch for the GitLab incoming email token issue?

No. GitLab treats it as intended behavior and changed only its UI text and documentation. The fix is on each user: reset the token and keep the address private.

What happens when I reset the token?

Every issue-by-email address you’ve used stops working at once, across all projects. Anyone who legitimately files issues by email will need the new address.

Developer-platform and supply-chain risks like this land in the CyberExperts Daily Brief each weekday morning, with the one setting to change.

Sources

George Bailey

George Bailey is a cybersecurity researcher and writer at CyberExperts, covering cyber threats, AI, cloud security, vulnerabilities, and defensive strategies. His goal is to help security professionals quickly understand what matters most and how it impacts their organizations.