GitLab's 'Incoming' Email Token Turns Email Into a Supply-Chain Weapon

September 23, 2026 — Aikido Security published research today documenting how GitLab's "incoming" email address, presented in the UI as a tool for creating issues via email, contains a long-lived token that lets anyone who possesses it push code to any branch — including main — and execute CI/CD jobs while impersonating the victim user. The mechanism bypasses both IP restrictions and two-factor authentication. GitLab changed the interface text after the report, but the behavior remains unchanged.

The Credential That Looks Like an Email Address

The core discrepancy, documented by Aikido Security, lies between the mental model GitLab's interface presents and the underlying technical reality. Users are shown an email address "to create issues in this project." In reality, as the researcher demonstrated, the embedded glimt- token is identical across all of an account's projects. Aikido opened the "Email work item to this project" function in five different projects: GitLab returned five distinct addresses, but the glimt- token inside them was the same, even for private projects.

This token is long-lived and does not expire. Aikido explicitly defines it as "a long-lived token tied to your account, and it never expires." Its scope is the entire account: public projects, private projects, groups, and — if the victim's role permits — execution of CI/CD pipelines.

From Issue to Merge Request: The Tested Attack Path

The proof of concept developed by Aikido exploits a simple alteration of the address suffix. Switching from -issue@... to -merge-request@... and attaching a patch opens a merge request. GitLab applies the patch to the specified branch: "pushes to that branch if it exists and creates it if it doesn't," the researcher documented. The resulting commit is signed with the victim's identity.

If the patch modifies the .gitlab-ci.yml file and the victim's role allows job execution, GitLab runs the pipeline as that user. Aikido confirmed this path: "If the patch touches .gitlab-ci.yml and the victim's role allows it, GitLab runs the attacker's job." The researcher also verified reading CI/CD variables and secrets from private projects, and exfiltrating source code from repositories behind IP allowlists.

Bypassing Perimeter Controls

The mechanism evades two standard security controls. On IP restrictions, Aikido tested with a private project limited to a single IP address not owned by the researcher. The result: "GitLab blocked our browser and rejected our git clone commands. But it still accepted a merge request email." The commit was applied to main despite the perimeter block.

On 2FA, The Hacker News reported that GitLab's official documentation states incoming email features "work without 2FA, even on instances that require it." Email thus becomes a privileged channel that expressly ignores a fundamental authentication control.

"GitLab built a credential that reaches every project in the account and bypasses IP restrictions, then presented it as an email address."

Public Addresses, Concrete Threat

Aikido mapped the exposed attack surface. In an afternoon of research, the researchers found roughly a dozen "incoming" email addresses intentionally published in READMEs, contribution guides, and support pages of open-source projects. These addresses, shared to receive bug reports, are active credentials that allow writing into the project's supply chain and the maintainer's account.

GitLab's response to the disclosure reveals a threat-modeling gap. The first report, submitted via HackerOne in May 2026, was closed as "intended behavior." A second report via confidential issue was opened in June 2026. After these reports, GitLab changed the UI text: it added "and merge requests" and removed the phrase "cannot be used to access any other data." The technical behavior did not change.

GitLab opened an internal issue to evaluate accepting email only from verified addresses, but the status of this measure is "under consideration": not implemented, not scheduled.

What to Do Now

• Check exposure: Users with Maintainer roles or higher should check whether their "incoming" email address has been published in public documentation, READMEs, or contribution guides.
• Rotate the token: From the personal access tokens page, users can regenerate the glimt- token, invalidating previously exposed addresses.
• Monitor email-created merge requests: Teams should enforce mandatory code-review checks for merge requests created via email, if this feature is used in sensitive projects.
• Evaluate the feature: Self-managed organizations should verify whether incoming email is enabled and assess its necessity against the documented risk; on GitLab.com the feature is enabled by default.

The Pattern of Productivity Becoming a Vector

The GitLab case is not a bug in the classic sense: there is no implementation error to patch. It is instead a productivity feature — receiving issues via email — that turns an apparently harmless identifier into a credential with implicit, uncontrollable privileges. The vendor chose to relabel the interface rather than redesign the authorization model.

For companies using GitLab, the critical point is that every user with elevated permissions represents a supply-chain risk node if their tokenized email address is exposed. For the industry, the pattern is broader: features designed to reduce friction end up subverting standard security controls. When the email "for creating issues" can write to main, the problem is not technical but one of alignment between user expectations and authorization architecture.

Sources

• https://thehackernews.com/2026/09/a-leaked-gitlab-issue-email-address.html
• https://www.rescana.com/post/active-exploitation-alert-critical-gitlab-vulnerability-cve-2026-19478-targeted-within-24-hours-of-disclosure
• https://tech-insider.org/gitlab-cve-2026-19478-cvss-9-4-exploit-2026/
• https://github.com/hackeremmen/gitlab-exploit
• https://www.aikido.dev/blog/gitlab-email-push-to-main
• https://tech-insider.org/gcp-workload-identity-federation-setup-2026/
• https://nvd.nist.gov/vuln/detail/CVE-2026-19478
• https://support.github.com/
• https://about.gitlab.com/releases/2026/08/19/security-release-gitlab-19-2-4-released/
• https://advisories.gitlab.com/
• https://github.com/hackeremmen/gitlab-exploit/issues

Information verified against cited sources and current as of publication.

Sources