GitLab Email Addresses Can Be Weaponized for Supply Chain Attacks

GitLab's Per-User Incoming Email Address Doubles as an Unexpiring Access Token

GitLab automatically issues every user on the platform a private "incoming email" address for creating issues by email — a convenience feature also found on tools like Trello and Todoist. Research published September 23, 2026 by Aikido Security researcher Joe Leon found that GitLab's implementation goes much further than issue creation: the address embeds a long-lived, account-wide access token that, according to Aikido, functions as "both authentication and authorization" for anyone who obtains it — no login, no two-factor prompt, and no IP allowlist check required.

Details

How It Works

An address that looks project-scoped but isn't

Every GitLab project issue-tracker page displays a unique-looking incoming email address in the form incoming+project-id-glimt-token-issue@incoming.gitlab.com. The interface presents this as tied to that specific project, but Aikido found that the glimt- token segment is actually generated once per user account — the same token appears embedded in the address for every project that user can access. Anyone who obtains a single leaked address effectively holds a master key to that user's entire footprint on the platform, not just one repository.

From "create an issue" to "push to main"

GitLab's mail handler does not verify that an incoming message actually originated from the token owner's mailbox — the token in the address is treated as sufficient proof of identity. Aikido demonstrated that swapping the -issue suffix for -merge-request, attaching a Git patch file, and naming a source branch in the email subject causes GitLab to apply that patch as a merge request authored by the token's owner. If the victim holds Maintainer rights, the patch can land directly on a protected branch, including main, with the commit attributed to the victim's identity.

CI/CD execution and secrets exposure

Because a submitted patch can modify .gitlab-ci.yml, an attacker-controlled pipeline definition executes inside the victim's project the moment the merge request is created. Aikido's researchers confirmed this path could be used to exfiltrate private source code, read CI/CD variables and secrets, and leverage the job-scoped CI_JOB_TOKEN to reach further into connected resources. The same route also allows retrieval of confidential issues via GitLab's /move quick action.

Bypassing IP allowlists and two-factor authentication

To test real-world impact, Aikido configured a private test project to accept connections only from an unrelated, unauthorized IP address. Standard browser access and git clone over HTTPS/SSH were correctly blocked. The emailed patch, however, was processed normally and landed a commit on main — because inbound mail processing sits outside the IP-restriction and 2FA enforcement paths entirely. Organizations relying on IP allowlisting as a compensating control for sensitive repositories have no equivalent protection against this route.

Impact Assessment

Recommendations

For GitLab administrators

• Treat every incoming-email address as a live credential, not a UI convenience. Audit where these addresses have been shared, documented, or committed to code.
• On self-managed instances, evaluate whether the incoming email feature is required; disable it where it is not in active use.
• Monitor for unexpected merge requests or issues originating from mail-gateway intake, particularly changes touching .gitlab-ci.yml.

For DevOps and platform teams

• Rotate incoming-email tokens immediately by resetting the address from the personal access tokens page in your GitLab profile — this replaces the token for all projects at once, so distribute the new address to legitimate automation before the old one stops working.
• Run secret-scanning tooling (custom rules or updated GitLab-aware scanners) against repositories, wikis, and ticketing systems for the glimt- token pattern, the same way you would hunt for leaked API keys.
• Do not treat IP allowlisting as a substitute for token hygiene on repositories with sensitive CI/CD pipelines or protected branches.

For security teams

• Add GitLab incoming-email addresses to your organization's secrets inventory and rotation cadence rather than treating them as low-sensitivity metadata.
• Review recent merge request and CI/CD pipeline history for activity attributed to high-privilege accounts (Maintainer/Owner) that does not match known user behavior.
• Track GitLab's response for further hardening — Leon's team noted GitLab has opened an internal issue to explore verifying that incoming mail actually originates from the token owner, though no such control exists today.

Key Takeaways

1. GitLab's per-project incoming email address embeds a single, account-wide token that grants the same access across every project the user can reach — not just the project shown in the UI.
2. The token never expires by default and requires no additional authentication; possessing the address is enough to act as its owner.
3. A leaked address can be escalated from simple issue creation to pushing commits on protected branches and triggering malicious CI/CD pipelines.
4. This attack path bypasses IP allowlists and two-factor authentication entirely, since mail intake is processed outside those controls.
5. GitLab has classified the reported behavior as intended design rather than a vulnerability and has so far only updated documentation, meaning the underlying risk persists for organizations that don't proactively rotate tokens.
6. Immediate mitigation requires manual token rotation and secret-scanning for glimt- patterns — there is no patch to apply.

Sources

• GitLab Email Addresses Can Be Weaponized for Supply Chain Attacks — Dark Reading