Full Report
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. [...]
Analysis Summary
# Vulnerability: Unauthorized Repository Access via Exposed GitLab Service Email Tokens
## CVE Details
- **CVE ID**: N/A (Currently classified by vendor as "Intended Behavior/Feature," though tracking for mitigation is under GitLab Work Item #617883)
- **CVSS Score**: N/A (Estimated High: 7.5 - 8.5 range based on potential for unauthorized code injection)
- **CWE**: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor / CWE-306: Missing Authentication for Critical Function
## Affected Systems
- **Products**: GitLab (Self-managed and GitLab.com)
- **Versions**: All versions supporting the "Email work item to this project" feature.
- **Configurations**: Projects where "Issues" or "Merge Requests" via email are enabled, and where the unique project email address (containing the `glimt-` token) has been shared publicly.
## Vulnerability Description
GitLab provides a feature allowing users to create issues or merge requests by sending an email to a unique, system-generated address. This address contains a long-lived authentication token (`glimt-` prefix) tied to a specific user account.
The flaw is not a software bug in the traditional sense, but a **cryptographic/logic bypass** resulting from how GitLab processes these emails:
1. **Lack of Origin Verification**: GitLab does not verify if the "From" address of the incoming email matches the owner of the token. Any sender can spoof or send an email to this address.
2. **Predictable Suffixes**: An email address generated for issues (ending in `-issue`) can be manually modified by an attacker to `-merge-request`.
3. **Identity Impersonation**: GitLab processes the incoming email as if it were sent by the token owner, inheriting all their permissions, including the ability to push code to protected branches or trigger CI/CD pipelines.
## Exploitation
- **Status**: PoC Available / Actively observed in the wild (via misconfiguration).
- **Complexity**: Low (Requires only finding the exposed email and changing the suffix).
- **Attack Vector**: Network (Email).
## Impact
- **Confidentiality**: High (Access to private repositories, CI/CD variables, secrets, and confidential issues).
- **Integrity**: High (Ability to open merge requests and push unauthorized code into the codebase).
- **Availability**: Medium (Potential to disrupt CI/CD workflows or delete content via task manipulation).
## Remediation
### Patches
- **No software patch currently available** as GitLab considers this intended functionality. Users must rely on configuration management.
### Workarounds
- **Token Reset**: If a project email address has been exposed, the user must reset their incoming email token immediately via GitLab user settings.
- **Access Control**: Ensure that developers do not post these private addresses in `README.md`, contributing guides, or support forums.
- **Least Privilege**: Ensure users with these tokens do not have unnecessary administrative or maintainer rights to sensitive branches.
## Detection
- **Indicators of Compromise**:
- Unexpected Merge Requests or Issues created by users who claim they did not send them.
- Emails originating from external or unknown mail servers being processed as internal user actions.
- **Detection Methods**:
- Audit GitLab `production_json.log` for incoming email ingress.
- Scan public-facing documentation (READMEs, Wikis) for the string `glimt-`.
## References
- **Vendor Documentation**: hxxps[://]docs[.]gitlab[.]com/user/project/issues/create_issues/
- **GitLab Internal Tracking**: hxxps[://]gitlab[.]com/gitlab-org/gitlab/-/work_items/617883
- **Researcher Report (Aikido)**: hxxps[://]www[.]aikido[.]dev/blog/gitlab-email-push-to-main
- **Original News Source**: hxxps[://]www[.]bleepingcomputer[.]com/news/security/exposed-gitlab-project-email-addresses-let-attackers-push-code/