As reported by BleepingComputer, researchers at Aikido have surfaced a systemic exposure risk in GitLab's Email work item to this project feature — one that turns careless documentation hygiene into a direct path for unauthorized code contribution and CI/CD pipeline abuse.

Security Impact: As reported by BleepingComputer, researchers at Aikido have surfaced a systemic exposure risk in GitLab's Email work item to this project feature — one that turns careless documentation hygiene into a direct path for unauthorized code contribution and CI/CD pipeline abuse.

Why This Matters

GitLab's email-to-issue feature is designed for convenience: each project generates a unique email address containing a glimt- token that authenticates inbound emails and converts them into work items. The problem is that this token is the credential — it's long-lived, tied to a specific user's permissions, and GitLab does not verify that the sender address matches the token owner. Any mailbox on the internet can fire off an email and have it processed as that user.

The exposure vector is mundane but pervasive: teams paste these addresses into READMEs, CONTRIBUTING files, support portals, and bug-reporting guides so external contributors can file issues without GitLab access. In doing so, they're publishing a credential that grants the token owner's full permission set — up to and including pushing merge requests to protected branches, triggering CI/CD pipelines, and accessing pipeline secrets.

The Escalation Path

Why This Matters
Issue creation to merge request: Changing the -issue suffix to -merge-request causes GitLab to open a merge request instead of an issue — potentially against a protected branch if the token owner has maintainer or higher privileges.
CI/CD secret exposure: If an attacker can trigger a pipeline via a crafted merge request, they may be able to exfiltrate variables marked as masked or protected, depending on pipeline configuration and branch protection rules.
IP restriction bypass: Aikido confirmed that GitLab's IP allowlisting does not apply to inbound email processing — the SMTP gateway is a separate trust boundary.
Private project targeting: While public project paths and IDs are trivially discoverable, private project IDs can be brute-forced. The project path would need to be leaked, but this is a low bar for any motivated attacker.

Who Is at Risk

Any organization using GitLab self-managed or SaaS that has published project email addresses in publicly accessible locations is exposed. The blast radius scales with the permissions of the token-owning account. Development teams that embedded these addresses in open-source project documentation — where they're indexed by search engines and scraper tools — face the highest risk. Organizations using GitLab CI/CD with secrets stored in pipeline variables are at elevated risk of secret exfiltration if an attacker can trigger a pipeline execution path.

This isn't a novel vulnerability in GitLab's code — it's a design weakness where the credential delivery mechanism (an email address) is inherently shareable and the platform lacks sender validation. GitLab is reportedly considering adding sender-address verification, which would meaningfully reduce the attack surface.

Shield53 Recommendations

Immediate Actions

  • Audit public-facing documentation: Search all READMEs, CONTRIBUTING files, wikis, support pages, and external sites (GitHub mirrors, documentation portals) for any address containing the glimt- token string. Remove or redact immediately.
  • Reset compromised tokens: For any project where the email address was exposed, reset the token via GitLab's project settings. This invalidates the old address and generates a new one.
  • Review recent merge requests and issues: Check for unauthorized work items created via email — look for items where the author doesn't match expected team members or where the content appears injected.
  • Audit CI/CD pipelines: Review recent pipeline runs for unexpected triggers. Rotate any CI/CD variables or secrets that may have been exposed during suspicious runs.

Hardening & Ongoing Defense

  • Never publish project email addresses: Use GitLab's API or web interface for external issue collection instead. If email-based issue creation is required, route it through a dedicated service account with minimal permissions — never a maintainer or admin account.
  • Apply least privilege to token-owning accounts: Ensure the account tied to the email token has the minimum role necessary (Reporter or Developer, not Maintainer) to limit the impact of token leakage.
  • Enforce branch protection: Require approvals and status checks before merge. This adds a human review gate even if an attacker successfully opens a merge request.
  • Restrict CI/CD secret scope: Use environment-scoped variables and protected branch policies to ensure secrets aren't exposed in pipelines triggered from unreviewed merge requests.
  • Monitor GitLab audit logs: Alert on work items created via the email channel, especially merge requests created outside of normal working hours or from unexpected geographic sources.

The deeper lesson here is about credential hygiene in developer tooling. Features designed for convenience — email-to-issue, API tokens in CI configs, webhook secrets — frequently end up in places they don't belong. Security teams should treat any embedded token in developer documentation as a live credential exposure and build scanning into their CI/CD pipelines to catch these patterns before they ship to public repositories.