The disclosure around GitLab’s incoming email feature highlights an unusual but important security lesson: sometimes something that looks like an email address is actually an authentication credential.

GitLab allows users to create issues and merge requests simply by sending email to a project-specific address.

Embedded inside that address is a user-specific incoming email token.

The important detail is that this token does not expire automatically and is associated with the user rather than being isolated to one individual project.

GitLab’s current documentation explicitly states that the token must be kept secret because anyone who obtains it can create issues and merge requests as the affected user.

At first glance, that may sound like a nuisance issue involving forged tickets.

The actual security impact can be considerably greater.

The email address is effectively a bearer credential

The security model is based on possession of the generated address.

GitLab does not authenticate the sender of each incoming email against the account owner before applying the action.

If someone possesses the correct incoming email address, GitLab processes the request with the permissions associated with that token.

That makes the address conceptually similar to a bearer token:

whoever possesses it can exercise the capability it represents.

This distinction matters because people naturally treat an email address very differently from a password, API token, or SSH private key.

An email address may be:

  • copied into documentation;
  • pasted into issue templates;
  • shared with colleagues;
  • published in a README;
  • stored in support documentation; or
  • indexed by search engines.

If the address contains a reusable authentication token, those ordinary sharing habits become security risks.

One token can potentially affect multiple projects

Aikido Security, which investigated the behavior, found that project-specific incoming email addresses generated for the same user share the same underlying token.

The token follows the user across projects rather than being independently scoped to one repository.

That significantly increases the blast radius.

A developer may believe they are exposing an address for one project’s issue tracker.

In reality, leaking the embedded token may provide the holder with the user’s email-based capabilities across other GitLab projects to which that account has access.

The impact therefore depends heavily on the privileges of the compromised account.

A token belonging to a low-privilege guest user may have limited value.

A token belonging to a developer, maintainer, or privileged automation account can be considerably more serious.

The attacker can turn an issue address into a merge-request address

One of the most interesting findings is how easily the feature can move from issue creation into source-code modification.

Researchers demonstrated that the address format can be changed from an issue-oriented address to a merge-request address.

The attacker can then email a patch to GitLab and specify a target branch.

GitLab applies the patch and creates a commit attributed to the compromised user.

If the affected user has permission to push to the target branch, this can include important branches such as:

main

The security consequence therefore changes dramatically.

What initially appears to be:

unauthorized issue creation

can become:

unauthorized source-code modification.

CI/CD makes the impact substantially worse

The risk becomes especially serious if the attacker modifies:

.gitlab-ci.yml

or other CI/CD-related project files.

If the compromised user’s permissions permit the change and the pipeline executes, attacker-controlled jobs may run inside GitLab CI/CD infrastructure.

CI pipelines frequently have access to valuable resources such as:

  • deployment credentials;
  • package registry tokens;
  • cloud credentials;
  • signing keys;
  • container registries;
  • build secrets;
  • production deployment systems; and
  • internal network services.

The incident therefore moves beyond repository integrity.

A leaked incoming email token can potentially become a software supply-chain attack path.

The attacker may not need to compromise a developer laptop directly.

Instead, they can manipulate the trusted workflow that builds and deploys the software.

The commit can appear to come from a legitimate developer

Another particularly dangerous aspect is attribution.

The malicious commit is created using the permissions and identity associated with the compromised GitLab account.

To someone reviewing repository history, the change may appear to have been authored by a legitimate developer or maintainer.

That can weaken the effectiveness of casual manual review.

Security teams therefore need to distinguish between:

“this commit is attributed to this account”

and:

“this human intentionally created this commit.”

Those are not necessarily the same thing when alternate authenticated submission mechanisms exist.

Two-factor authentication does not necessarily stop this attack

GitLab’s incoming email functionality is designed to work independently of an interactive browser authentication session.

According to the research, the email pathway can therefore operate even where two-factor authentication is enforced on the user’s account.

This does not mean MFA is ineffective or unnecessary.

It means MFA protects specific authentication flows.

If an application provides another trusted authentication mechanism based on possession of a long-lived token, compromise of that token can bypass the need to perform the normal interactive login sequence.

This is a broader identity-security lesson:

Every alternate authentication mechanism becomes part of the account’s effective security perimeter.

IP allowlists may also provide less protection than expected

Aikido also tested GitLab’s IP restrictions.

The researchers configured a private project so that their normal source address was outside the allowed range.

Browser access and Git operations were blocked.

However, the incoming email mechanism still accepted the merge-request email and processed the commit.

That means organizations relying heavily on IP restrictions should understand whether alternate application channels are subject to the same controls.

Security policy can become inconsistent when:

  • browser login is restricted;
  • Git access is restricted;
  • API access is restricted;

but:

  • incoming email remains trusted.

Attackers naturally look for the path where the strictest security controls are not applied.

The token does not expire automatically

GitLab documents incoming email tokens as non-expiring.

That creates another risk.

A leaked credential may remain usable long after the user has forgotten it was ever exposed.

Unlike a short-lived session token, there is no natural expiration window that automatically closes the attack opportunity.

This makes accidental publication particularly dangerous.

An incoming email address copied into an old README or public support page could remain useful to an attacker months or years later unless the token is manually reset.

Public repositories can make exploitation easier

To target a particular GitLab project through this mechanism, an attacker also needs information identifying the project, including its path and numeric project ID.

For public repositories, both are generally easy to obtain.

Private projects require additional knowledge, although project IDs can sometimes be inferred or leaked through other channels.

This limits the attack somewhat, but it should not be treated as a strong security boundary.

Repository names and internal project references routinely leak through:

  • documentation;
  • CI logs;
  • screenshots;
  • package metadata;
  • support tickets;
  • developer forums; and
  • external integrations.

Why this matters for software supply-chain security

GitLab sits directly in the software development lifecycle.

A privileged repository account may influence:

source code → build pipeline → package → container image → deployment → production

If an attacker gains the ability to inject code near the beginning of that chain, the compromise can potentially propagate through every stage that follows.

This is why apparently minor developer-platform authentication weaknesses deserve disproportionate attention.

A single unauthorized commit may eventually become:

  • a malicious package release;
  • a poisoned container image;
  • a backdoored application build; or
  • an unauthorized production deployment.

The severity depends on project permissions and CI/CD architecture, but the possible blast radius can be enormous.

Organizations should search for leaked incoming email addresses

One of the most practical actions is to treat GitLab incoming email addresses as secrets.

Organizations should search:

  • public Git repositories;
  • README files;
  • documentation;
  • wiki pages;
  • issue templates;
  • support portals;
  • archived mailing lists; and
  • internal documentation

for accidentally exposed GitLab incoming email addresses or tokens.

GitLab incoming email tokens use the prefix:

glimt-

in current default configurations.

That creates a useful secret-scanning opportunity.

Organizations that already scan repositories for:

glpat-

personal access tokens should consider adding equivalent detection for:

glimt-

incoming mail tokens.

Rotate the token if exposure is suspected

GitLab provides a mechanism to reset the incoming email token from the user’s access-token settings.

Resetting the token invalidates existing project-specific email addresses generated from the old token.

Organizations should rotate the token immediately where:

  • an address has been posted publicly;
  • it has been included in a leaked document;
  • repository history contains it;
  • it has been shared beyond the intended audience; or
  • suspicious email-created issues or merge requests are discovered.

Because one token is reused across project-specific addresses for the user, resetting it is particularly important after any exposure.

Self-managed GitLab administrators have additional options

On self-managed GitLab deployments, administrators can disable incoming email functionality at the instance level if the feature is not required.

That may be appropriate for organizations that do not rely on email-generated issues or merge requests.

Removing unused authentication pathways is one of the simplest forms of attack-surface reduction.

If nobody in the organization needs to submit code-related actions through email, maintaining that capability introduces risk without corresponding operational value.

Monitor repository activity by creation mechanism

Security teams should also consider monitoring how sensitive commits and merge requests are created.

High-value repositories should generate additional scrutiny for:

  • commits to protected branches;
  • modifications to .gitlab-ci.yml;
  • pipeline configuration changes;
  • new deployment jobs;
  • unexpected package publication;
  • secret-access changes; and
  • commits generated through unusual channels.

A trusted developer identity should not automatically suppress scrutiny when the method used to create the change is unusual.

Protect CI/CD secrets from repository compromise

The disclosure also reinforces the need to minimize what a compromised repository identity can reach.

CI/CD pipelines should follow least privilege.

Where possible:

  • production secrets should not be exposed to every job;
  • protected variables should be limited to protected refs;
  • deployment credentials should be short-lived;
  • jobs should receive only the credentials they need;
  • sensitive production actions should require additional approval; and
  • high-risk pipeline modifications should trigger review.

If modifying one CI configuration file immediately exposes every production credential, then the pipeline itself is functioning as a credential warehouse with YAML attached.

Branch protection remains important

Protected branches can reduce some of the impact, depending on how permissions and approval requirements are configured.

Organizations should require appropriate review for high-value branches and avoid allowing broad groups of users to push directly to main.

However, branch protection should not be treated as a substitute for credential protection.

If the leaked token belongs to a user who legitimately possesses sufficient privileges, the attacker inherits those privileges through the token.

Least privilege therefore remains crucial.

GitLab now explicitly documents the token as sensitive

GitLab's current documentation is clearer than older descriptions.

It now states that the incoming email token does not expire, must be kept secret, and allows anyone possessing it to create issues and merge requests as the user.

GitLab also changed descriptive text following Aikido's report, but according to The Hacker News, the underlying behavior has not fundamentally changed.

GitLab is reportedly considering restricting incoming email so that messages must originate from an email address verified on the user's account, but that protection was not yet implemented at the time of reporting.

This is as much a UX problem as a security problem

One of the broader lessons is that security-sensitive credentials must look and behave like credentials.

Users understand that a string labeled:

API TOKEN – KEEP SECRET

is dangerous to publish.

They may not apply the same caution to something presented primarily as:

“Email work item to this project.”

Security design should account for how people interpret an interface.

If possession of an email address grants authenticated actions, the interface should communicate that the address is functionally equivalent to a secret.

Otherwise the system creates a mismatch between the credential's technical power and the user's perception of its sensitivity.

The broader cybersecurity lesson

The GitLab disclosure demonstrates how modern application security increasingly depends on identifying hidden authentication channels.

Developers commonly think about credentials as:

  • passwords;
  • SSH keys;
  • personal access tokens;
  • API keys; and
  • OAuth tokens.

But functionality such as incoming email can create another credential class that is easier to overlook.

In this case, the path can become:

leaked email address → reusable account token → forged merge request → unauthorized commit → CI/CD execution → possible access to deployment secrets

The attacker may never know the user's password.

They may never defeat MFA.

They may never connect from an allowed IP address.

They simply use a different trusted pathway.

That is the central security lesson:

An identity is only as secure as the weakest mechanism allowed to act on its behalf.

Organizations should therefore inventory not just who can access development systems, but every mechanism capable of performing authenticated actions as those users.

Because when an email address can modify source code and trigger CI/CD, it stopped being “just an email address” quite some time ago.

The private email address GitLab gives you for filing issues by email is a credential. Anyone who gets it can email a patch that GitLab commits in your name, to any branch you can push to, including main, and can start CI/CD jobs that run as you. GitLab shows each user this address behind a button labeled "Email work item to this project." Mail sent to it opens an issue in that project, authored

Source: A Leaked GitLab Issue Email Address Lets Anyone Push Code and Run CI Jobs as You via The Hacker News — published 23 Sep 2026.