← All stories
● Covered by 1 source · 1 reportMedium impact1 negative

GitLab Email Address Vulnerability Allows Unauthorized Code Pushes and CI Job Execution

🔄 Updated 9h ago
New to BrevFeed? We gather this story from every outlet covering it into one summary — ranked by real-world impact, not just the latest headline — so you never miss what matters. What is BrevFeed? →

Key points

  • GitLab's private issue-by-email address is a credential.
  • Anyone with the address can commit code and run CI/CD jobs as the user.
  • The token in the address is tied to the account and does not expire.
  • GitLab does not verify the email sender, only the address itself.

GitLab Email Address Functions as a Credential

GitLab provides users with a private email address to file issues by email. This address functions as a credential, allowing anyone who obtains it to email patches that GitLab commits in the user's name. These actions can be performed on any branch the user has push access to, including the main branch, and can initiate CI/CD jobs that run under the user's identity.

Shared Token Across Projects and Lack of Sender Verification

The string in the middle of this email address is a non-expiring token linked to the user's account. Aikido Security discovered that this token is shared across all projects associated with a user, both public and private. GitLab does not verify the sender of emails sent to this address, meaning any mailbox can send a message, and GitLab will process it as if it originated from the legitimate user, granting the sender the user's permissions without requiring access to their mailbox.

Exploiting for Code Commits and CI/CD Execution

Beyond filing bugs, this vulnerability can be exploited to commit code. By changing the address suffix from '-issue' to '-merge-request', an attacker can create a merge request. Attaching a patch and specifying a target branch in the email subject allows GitLab to apply the patch to that branch, creating it if it doesn't exist. This results in a commit authored by the legitimate user. If the patch modifies the project's '.gitlab-ci.yml' file and the user's role permits, GitLab will execute the attacker's CI/CD job as the user.

Scope of Impact and Mitigating Factors

The extent of an attacker's capabilities depends on the compromised user's permissions; a Guest account's leaked address offers minimal utility, while a Maintainer's could access protected branches and CI/CD secrets. To target a specific project, an attacker also needs the project's path and numeric ID. Public projects openly display this information, while private projects require additional access.

✨ This summary was generated by AI from the outlets' reporting listed below. It is not independently verified and may contain errors — check the original sources. How BrevFeed works →

The daily brief

One email each morning: the day's tech stories, clustered across outlets and summarized. No account needed.

One email a day. Unsubscribe in one click, any time.

Today's brief

Spend a few minutes, get the whole day. Every topic's top stories in one hands-free rundown — listen, watch, or read the transcript.

~26 min · 21 stories · Sep 23

▶ Play today's brief Listen on Spotify

New every morning, and the back catalogue is archived by date.

Reporting from

A vulnerability in GitLab's issue-by-email feature allows anyone with a user's private email address to push code and run CI/CD jobs as that user. This occurs because the email address acts as a credential, and GitLab does not verify the sender, enabling unauthorized actions on any project the user can access.