Full Report
The private email address GitLab gives you for filing issues by email is a credential. Anyone who gets it can email a patch that GitLab commits in your name, to any branch you can push to, including main, and can start CI/CD jobs that run as you. GitLab shows each user this address behind a button labeled "Email work item to this project." Mail sent to it opens an issue in that project, authored
Analysis Summary
# Vulnerability: Unauthorized Code Execution via Leaked GitLab Issue Email Addresses
## CVE Details
- **CVE ID**: Not specified in the source (Reported by Aikido Security)
- **CVSS Score**: Not provided (Estimated High/Critical based on potential for RCE/Supply Chain compromise)
- **CWE**: CWE-287 (Improper Authentication), CWE-822 (Untrusted Pointer Dereference - *Contextual*)
## Affected Systems
- **Products**: GitLab.com (SaaS) and GitLab Self-Managed.
- **Versions**: All versions supporting "Email work item" and "Merge request by email" features.
- **Configurations**:
- Self-managed instances with "Incoming Email" enabled (default on GitLab.com).
- Specifically affects users who have shared or leaked their unique "Email work item" address.
- GitLab Dedicated is reportedly not affected.
## Vulnerability Description
GitLab provides users with unique email addresses to create issues or merge requests via email. This address contains a sensitive token tied to the user's account. Research by Aikido Security revealed several flaws in this implementation:
1. **Token Reusability**: The same token is used across all projects a user has access to.
2. **Authentication Bypass**: GitLab does not verify the `From` address of the incoming email; it assumes the sender is the user associated with the token.
3. **Feature Extension**: By changing the suffix of the address from `-issue` to `-merge-request`, an attacker can submit code patches.
4. **Security Control Bypass**: Incoming email bypasses Two-Factor Authentication (2FA) and IP allowlist restrictions.
## Exploitation
- **Status**: PoC available/verified by researchers; live leaked addresses found in the wild.
- **Complexity**: Low (Requires only the leaked email address and the target Project ID).
- **Attack Vector**: Network (Email).
## Impact
- **Confidentiality**: **High** (Attackers can interact with private projects if the project ID is known).
- **Integrity**: **High** (Attackers can commit code to any branch, including `main`, and trigger CI/CD pipelines as the victim).
- **Availability**: **Medium** (Potential to disrupt services via malicious CI/CD jobs or code deletion).
## Remediation
### Patches
- As of the report date, a specific software patch is not listed; the issue resides in the architectural design of the "Incoming Email" feature.
### Workarounds
- **User Level**: Immediately reset your "Incoming email token" via the **Personal Access Tokens** page in your GitLab profile.
- **Admin Level**: For self-managed instances, administrators can disable the "Incoming Email" feature entirely at the instance level.
- **Audit**: Review READMEs and documentation to ensure private issue email addresses have not been inadvertently published.
## Detection
- **Indicators of Compromise**:
- Unexpected commits or Merge Requests authored by users who claim not to have made them.
- Unauthorized CI/CD jobs running under a specific user's context.
- Merge Requests created via the email gateway (check GitLab logs for `incoming_email` activity).
- **Detection Methods**: Monitor system logs for incoming email activity that results in commits to protected branches.
## References
- Aikido Security Research: [https://www.aikido.dev/blog/gitlab-email-push-to-main](https://www.aikido.dev/blog/gitlab-email-push-to-main)
- GitLab Documentation - Incoming Email: [https://docs.gitlab.com/administration/incoming_email/](https://docs.gitlab.com/administration/incoming_email/)
- The Hacker News: [https://thehackernews.com/2026/09/a-leaked-gitlab-issue-email-address.html](https://thehackernews.com/2026/09/a-leaked-gitlab-issue-email-address.html)