Reported by 9 outlets
GitLab Email Feature Lets Attackers Push Code to Protected Branches and Execute CI/CD Jobs
Why this score
- Breadth
- 2.00 / 2.0 · 9 sources
- Authority
- 1.80 / 2.0 · best outlet weight
- Severity
- 0.50 / 5.0 · CVSS + content signals
- Velocity
- 0.00 / 2.0 · updates in 48h
- Pickup speed
- 0.00 / 0.6 · time to second source
- Recency
- × 0.00 temporal multiplier
- Community
- + 0.00 / 1.5 · reddit signal
- Score
- 0.0 / 10 = base × recency + community
Desk analysis
Joe Leon of Aikido Security disclosed on September 23 that GitLab's "Email work item to this project" feature embeds a long-lived, account-scoped credential, the glimt- string, in the project email addresses it generates. The token carries nine permissions including repository update and protected branch update. Swapping the -issue suffix in the address to -merge-request makes GitLab open a merge request from an emailed git .patch attachment, so anyone holding the address can push attacker-controlled code with the token owner's permissions and trigger CI/CD jobs. Incoming email is explicitly excluded from GitLab IP restrictions, so allowlists do not stop this path. Aikido found about a dozen live addresses published in READMEs, contributing guides, and support pages, and notes GitLab had closed a May 2026 HackerOne report on the mechanism as intended behavior.
GitLab's shipped fix is documentation-only: a change merged August 10 into milestone 19.3 removed the claim that the token cannot access other data and added wording that incoming email bypasses IP restrictions. The mechanism itself is unchanged. A feature issue proposing that token actions be accepted only from the owner's verified email address was created August 19, remains unassigned, and targets milestone 19.5 due October 9, with maintainers warning a default-on change could break forwarded-mail and automation workflows. GitLab's concurrent critical patch release 19.4.1, 19.3.3, and 19.2.7, flagged by Canada's Cyber Centre as AV26-962 on September 25, addresses other flaws and does not change this design.
Treat any exposed project email address as a working credential to a repository: code push to protected branches, secret collection from CI/CD variables, and access to confidential issues are all in scope for the token owner's rights. Rotate exposed glimt- tokens now, scrub addresses from public documentation, and watch milestone 19.5 for a real sender-verification control.
Timeline
-
original reporting
GitLab Email Feature Lets Attackers Push Code to Protected Branches and Execute CI/CD Jobs
cyberpress.org · 19d ago · September 24th, 2026
A GitLab feature designed to let users create work items through email can be abused as an account-level code delivery mechanism, potentially allowing attackers to push commits to protected branches and execute CI/CD pipelines when a private incoming-email address is exposed. Security researcher Joe Leon of Aikido Security found that GitLab’s “Email work item to this project” option generates an address containing a long-lived incoming email token. Although GitLab presents the address as a project-specific method for creating issues, the embedded credential can apply across every project the affected user can access. GitLab Email Feature Lets Attackers Push Code The address follows a format similar to incoming+project-id-glimt- -issue@incoming.gitlab.com . The glimt- value acts as an authentication token that does not expire by default. Aikido’s research found that the same token appears in email addresses generated for multiple projects, including private repositories , making it an account-scoped credential rather than a project-scoped one. An attacker who obtains a victim’s incoming-email address can reportedly change the address suffix from -issue to -merge-request and submit a Git patch as an attachment. By specifying a source branch in the email subject, the attacker can cause GitLab to apply the patch to an existing branch or create a new branch under the victim’s identity. If the target account is authorized to push to a protected branch, the attacker may be able to c
-
update from gitlab.com
Merge request !247431: Align incoming email token capability across UI and docs
gitlab.com · 64d ago · August 10th, 2026
GitLab's shipped response to the incoming email token issue, opened July 28, 2026 and merged August 10, 2026 into milestone 19.3. Changes are copy-only: it removed the claim that the token cannot access any other data, added 'and merge requests' to the UI modal and token description, and documented that incoming email is not subject to IP restrictions. The underlying mechanism was left unchanged.
-
update from gitlab.com
Work item #617883: Email verification for incoming email token actions
gitlab.com · 55d ago · August 19th, 2026
Open GitLab feature issue, created August 19, 2026, proposing that incoming email token actions be accepted only from a verified email address tied to the token owner's account. Still in New state and unassigned, targeted at milestone 19.5 due October 9, 2026; GitLab maintainers noted that enabling it by default could be a breaking change for forwarded-mail and automation use cases.
-
update from aikido.dev
Send GitLab an email, push to main
aikido.dev · 20d ago · September 23rd, 2026
Original researcher disclosure by Joe Leon of Aikido Security, published September 23, 2026 (RSS pubDate Wed, 23 Sep 2026 06:00:00 GMT), roughly a day before the story's first_seen. Details the account-scoped, non-expiring glimt- incoming email token, the -issue to -merge-request suffix swap with a git .patch attachment, the IP-restriction bypass demonstrated against a private project, and the nine token permissions including repository update and protected branch update. Reports GitLab closed the May 2026 HackerOne submission as intended behavior, and that Aikido found a dozen live incoming addresses published in public documentation.
-
update from gbhackers.com
GitLab Email Token Lets Attackers Push Code to Main and Execute CI/CD Jobs
gbhackers.com · 19d ago · September 24th, 2026
This issue can also bypass GitLab’s IP restrictions, as incoming email is explicitly excluded from those controls. […] The post GitLab Email Token Lets Attackers Push Code to Main and Execute CI/CD Jobs appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform .
-
update from beyondmachines.net
GitLab Incoming Email Addresses Enables Code Push, Running CI/CD Jobs, Bypass IP Restrictions GitLab's incoming email feature uses a persist
beyondmachines.net · 19d ago · September 24th, 2026
GitLab Incoming Email Addresses Enables Code Push, Running CI/CD Jobs, Bypass IP Restrictions GitLab's incoming email feature uses a persist
via Mastodon https://beyondmachines.net/event_details/gitlab-incoming-email-addresses-enables-code-push-running-ci-cd-jobs-bypass-ip-restrictions-0-r-z-l-8/gD2P6Ple2L
-
update from bleepingcomputer.com
Exposed GitLab project email addresses let attackers push code
bleepingcomputer.com · 19d ago · September 24th, 2026
Private GitLab email addresses that allow developers to push issues or tasks to a project are being deliberately exposed in READMEs, contributing guides, and support pages used to collect bug reports. When an external client sends a message to one of them, GitLab parses it into a project issue or task. Researchers at application security company Aikido found multiple private GitLab addresses exposed in public documentation and are warning about the associated risk. Each of these private GitLab address embed a ‘glimt-’ string that acts as a credential for accessing the project, which persists across all similar addresses generated for the respective project.
-
mentioned by www.bleepingcomputer.com
Exposed GitLab project email addresses let attackers push code https:// bleepingcomputer.com/news/security/ exposed-gitlab-project-email-add
www.bleepingcomputer.com · 19d ago · September 24th, 2026
-
update from malware.news
GitLab security advisory (AV26-962)
malware.news · 18d ago · September 25th, 2026
Serial number: AV26-962 Date: September 25, 2026 As of September 23, 2026, GitLab is affected by vulnerabilities in the following product: GitLab Prior to 19.2.7 Prior to 19.3.3 Prior to 19.4.1 The Cyber Centre encourages users and administrators to review the provided web links and apply any necessary updates as they become available. GitLab Critical Patch Release: 19.4.1, 19.3.3, 19.2.7 GitLab release notes | GitLab Docs Article Link: GitLab security advisory (AV26-962) - Canadian Centre for Cyber Security
-
update from www.infoworld.com
GitLab issue emails protected only by obscurity of the reply-to address
www.infoworld.com · 18d ago · September 25th, 2026
GitLab email notifications for issues rely on obscurity as their only security layer, meaning anyone who intercepts or guesses the reply-to address can reach the notifications. via Mastodon https://www.infoworld.com/article/4226735/gitlab-issue-emails-only-security-is-obscurity.html
-
mentioned by www.bleepingcomputer.com
Exposed # GitLab project # email addresses let attackers push code https://www. bleepingcomputer.com/news/secu rity/exposed-gitlab-project-e
www.bleepingcomputer.com · 18d ago · September 25th, 2026
-
update from www.darkreading.com
GitLab Email Addresses Can Be Weaponized for Supply Chain Attacks https://www. darkreading.com/application-se curity/gitlab-email-addresses-
www.darkreading.com · 18d ago · September 25th, 2026
GitLab Email Addresses Can Be Weaponized for Supply Chain Attacks https://www.