GitLab’s Issue Email Is an Account-Wide Credential That Ignores Your IP Allowlist
GitLab gives every project a private email address — “Email work item to this project” — so developers can file issues by sending mail. According to research from Aikido Security, reported by InfoWorld on September 25, that address embeds a long-lived token that reaches far beyond issue filing: anyone holding it can push code, open merge requests with crafted patches, and execute CI/CD jobs across every project the account can reach — public and private — while ignoring IP allowlists entirely. The feature is enabled for every account on GitLab.com and cannot be switched off.
GitLab’s position is that the behaviour is intended, not a vulnerability. Read Aikido’s findings and decide whether that distinction helps you.
One token per account, dressed up as five addresses
Addresses take the form incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com. The glimt- segment is a personal access token — and Aikido found the token embedded in five different projects’ addresses on the same account is identical. Compromise one project’s “private” address and you hold a credential scoped to the whole account. GitLab’s UI warns “Keep this token secret. Anyone who has it can create issues as if they were you,” and further claims the token “cannot be used to access any other data” — a claim Aikido’s testing falsifies. After the report, GitLab updated the UI text to acknowledge the token also creates merge requests. The scope did not change; only the label did.
The escalation path is a suffix swap. Changing -issue in the address tricks GitLab into opening a merge request instead, letting the sender submit a crafted patch and have project CI execute attacker-controlled code. Capability remains bounded by the victim account’s own permissions — “the organisational impact depends entirely on the user’s existing permissions,” researcher Joseph Leon told reporters — but for maintainers who can push to main and run pipelines, the email address inherits all of it. Reaching other projects requires their path and ID: public information for public projects, and for private ones a leaked path plus a guessable ID.
The IP allowlist does not apply to email
The detail that should end debate in most threat models: GitLab lets users restrict account access by IP address, but those restrictions are not enforced on the email channel. Aikido’s proof is a clean A/B — “GitLab blocked our browser and rejected git clone. It accepted the email, and the commit landed on main.” An organisation that carefully allowlisted its GitLab access to office and VPN ranges still accepts unauthenticated writes from any mail server on earth, authenticated only by possession of an address that users routinely paste into docs, tickets, and chat. Aikido’s Leon reports finding a dozen or so exposed addresses after a couple of hours of looking, including ones belonging to popular open-source projects such as wget2. As Leon put it, had GitLab required the sender’s From address to match the GitLab user’s email, most of the risk would evaporate.
Why this lands harder than yesterday’s GitLab patch
Just yesterday we covered GitLab’s critical patch for CI regex-parser RCEs plus Duo and MCP scope fixes — conventional vulnerabilities with CVEs, fixed builds, and scanner signatures. This is the opposite shape: no CVE, no patch, no malfunction. A documented feature whose credential scope exceeds its presentation, whose compensating control (IP restrictions) silently does not cover it, and whose remediation is entirely on the user — treat the address as a credential, hunt for exposures in public repos and documentation, and rotate the email token if in doubt. It belongs to the same family as the notification-path failure in the Australian Medicare incident: security-relevant communication travelling over channels nobody monitors as security-relevant.
For teams running agents with repository access, the exposure compounds. An agent that can read a leaked address from any ingested document — a mirrored repo, a support thread, pasted documentation — holds a push-and-execute credential with no IP binding and no expiry mentioned. Scope your machine users’ GitLab permissions as if their incoming-email address is already public, because statistically, sooner or later, it will be.
What to do
- Inventory every incoming-email address in your GitLab estate. Treat each one as a live credential with account-wide reach, not as a convenience endpoint.
- Search public surfaces for leaks. Grep public repositories, wikis, docs sites, and chat archives for
@incoming.gitlab.com. Assume anything indexed is held by someone. - Reset the email token wherever exposure is plausible. Rotation invalidates the leaked address; there is no finer-grained revocation for a single project’s address since the token is account-wide.
- Reduce the blast radius at the account level. The token inherits the account’s permissions, so strip push and pipeline-run rights from service accounts that only need to file issues, and segment high-privilege projects into accounts with minimal reach.
- Do not rely on IP allowlists for this channel. Until GitLab enforces sender matching or extends restrictions to email ingress, architect as though the allowlist has a documented hole shaped exactly like an email address.
Sources: