Skip to content
TrustList
News

A leaked GitLab project email address lets others act as its owner, and no fix is scheduled

Editorial

By TrustList Editorial

GitLab's "email to project" addresses carry a token that never expires. Anyone holding one can open merge requests and trigger pipelines as its owner. Reset the token and remove published addresses.

About A leaked GitLab project email address lets others act as its owner, and no fix is scheduled

A leaked GitLab project email address lets others act as its owner, and no fix is scheduled

23 September 2026 — Researchers at Aikido Security have shown that GitLab's "email a work item to this project" addresses can be used to act as the person who owns them. The finding was published on 23 September 2026 and reported by The Hacker News the same day and BleepingComputer on 24 September. There is no CVE and no dated fix, so the protection is in the hands of each GitLab customer.

What the problem is

GitLab generates a private email address for each project, so that people can create issues by email. The address contains an account-level "incoming email token". That token does not expire, and GitLab does not check who sent the email. Every project address belonging to one account uses the same token.

Aikido found that anyone holding one of these addresses can create issues and merge requests as the token's owner. It showed this can go further: pushing code to protected branches, running CI/CD jobs, reading CI secrets, and getting around IP restrictions and two-factor authentication. In one afternoon the researchers found about a dozen live addresses that people had published in README files, contributing guides and support pages.

GitLab's position

GitLab has updated the feature's description and treats the address as "a token like any other", The Hacker News reported. It has opened an issue about accepting such emails only from a verified sender address, but that is under consideration and not in place. GitLab.com and self-managed instances with incoming email enabled are affected; GitLab Dedicated appears not to be.

Who is affected

Any team on GitLab where someone has published a project email address, for example to let customers raise issues. The risk lands on the engineering organisation, but it becomes a supply-chain question for anyone who ships software built there.

What to do

  • Search your public repositories, documentation and help pages for GitLab project email addresses.
  • Anyone who has published one should reset their incoming email token from the personal access tokens page. This invalidates every project address on that account.
  • Review merge requests and pipeline runs created by email for anything unexpected, especially on protected branches.
  • Self-managed administrators can disable incoming email until GitLab verifies senders.

Sources