Back to all lessons
Awareness Lessons
2 days ago

GitLab Email Tokens Enable Unauthorized Code Pushes via Exposed Addresses

GitLab project email addresses, designed for bug report submission, inadvertently contain long-lived authentication tokens that function as credentials — creating a serious access control flaw when exposed publicly. Attackers discovered that simply modifying the '-issue' suffix to '-merge-request' in these addresses allows them to submit merge requests and push code to private repositories, entirely bypassing IP-based restrictions. This matters because long-lived tokens with broad implicit trust effectively become skeleton keys when leaked, enabling source code theft and secrets exposure. The core failure is a combination of poor secret hygiene (publishing email addresses containing tokens) and insufficient token scoping, compounding the risk that no expiration mechanism limits the window of exploitation.

Tactical Insight

Immediate actions

  • Audit all public-facing documentation, READMEs, and issue trackers to identify and remove any exposed GitLab project email addresses.
  • Immediately reset any compromised or publicly exposed email ingest tokens via GitLab project settings.
  • Disable email-based code submission features on any project that does not explicitly require them.

Long-term improvements

  • Replace long-lived static tokens with short-lived, scoped credentials and enforce automatic token rotation policies.
  • Implement a secrets scanning pipeline (e.g., GitLab Secret Detection, Gitleaks) to detect token leakage in commits, issues, and wikis before they are published.
  • Establish a formal configuration baseline for all GitLab projects that includes required privacy and access settings as part of project provisioning.

Detection measures

  • Enable and monitor GitLab audit logs for unexpected merge requests or code pushes originating from email-based submission channels.
  • Set up alerts for any merge requests submitted via email integration that originate from unrecognized or external senders.
  • Periodically review active project tokens and revoke any that are unused, undocumented, or older than a defined threshold.