Exposed GitLab Incoming Email Tokens Allow Unauthorized Code Modifications and CI Execution

1. Basic Information

• Original Title: Send GitLab an email, push to main
• Source: Aikido Security
• Published Date: 2026-09-23
• Updated Date: None
• Collected Date: 2026-09-25T08:28:50+09:00
• Severity: High
• Severity Rationale: Aikido demonstrated in a controlled test that exposed tokens allow code modifications, CI execution, and access to private data. While active exploitation in the wild has not been reported, the severity is rated high because long-lived token exposure impacts development infrastructure.
• Original Link: Send GitLab an email, push to main
• Related Sources: BleepingComputer: Exposed GitLab project email addresses let attackers push code, GitLab: Group access and permissions
• CVE: None
• Target Products and Services: GitLab, GitLab incoming email, GitLab CI/CD

2. Executive Summary

When a token included in a GitLab incoming email address is leaked, an unauthorized third party can modify code and run CI pipelines using the permissions of that user. This can affect multiple projects owned by the same user, but it does not provide a mechanism to gain permissions for separate accounts.

3. Attack Flow

This mechanism is described based on public information. Distinctions between researcher verification, implementation analysis, and actual exploitation are detailed in the success criteria section.

From Exposed Incoming Email Addresses to Code Modifications

1. A third party identifies a valid incoming email address and target project from public documents or other sources.
2. The attacker sends an email containing a patch to the merge request destination address.
3. GitLab processes branch creation and modifications under the permissions of the token owner. This is not a privilege escalation to projects or operations unauthorized for the owner.
4. If CI execution conditions are met, the modified job runs on the runner. Available secrets and external permissions depend on the configuration of the job and runner.

4. Attacker Position and Execution Environment

• The attacker knows a valid incoming email token and the target project, and has the ability to send messages to the incoming email feature.
• Operations within GitLab run with the permissions of the token owner, while processes inside the job run with the permissions assigned to the runner and the job.

5. Victim and Administrator Perspectives

Victims

• Branches, merge requests, and pipelines originating from emails not sent by the user may appear as their own actions.

Administrators

• Even without abnormal web logins, email receipt timestamps may correlate with code modifications and CI execution records.

6. Success and Failure Conditions

Success Conditions

• The incoming email feature is enabled, and the leaked token has not been revoked.
• The token owner has the necessary operational permissions in the target project, and the request meets the email processing criteria.
• CI-related impacts require target job execution conditions as well as permissions for secrets and external resources.

Failure Conditions and Risk Mitigation

• Reset the exposed incoming email token and disable the old address. Because this changes addresses for other projects owned by the same user, verify legitimate integrations.
• Reduce unnecessary project permissions and direct push rights to protected branches, and restrict CI secrets and runner permissions to necessary scopes.
• For GitLab Self-Managed, consider disabling the unused incoming email feature. Web or SSH IP restrictions alone cannot block email channels.

7. Impact of Successful Exploitation

• Code modifications, CI execution, and access to source code or sensitive information become possible within the scope of the owner's permissions and project settings.
• A token exposed in a single project may be leveraged across other projects belonging to the same user.

8. Observable Logs

The following guidance covers investigation and detection perspectives within your organization. It does not imply that all indicators were observed in public incidents.

Email

• Preserve the incoming email recipient, sender, attached patches, and processing results. Do not rely solely on the sender display name to determine legitimate operations.

Proxy, SWG, and DNS

• Check runners for suspicious outbound network connections. Web access logs alone cannot track email-initiated operations.

Endpoints and EDR

• Inspect runner jobs, child processes, artifact generation, and external data transmissions.

Authentication and IdP

• Verify token reset timestamps along with changes to owner permissions and group memberships.

SaaS and Cloud

• Review change histories for branches, merge requests, CI configurations, and pipelines. Individual reads of secret information are not always logged.

Network

• Correlate email receipt timestamps with outbound network traffic originating from jobs.

9. Determining Attack Success

Scope Confirmable via Public Information

• Initial Execution Confirmed: Public Information: Code changes and CI execution were confirmed during Aikido's controlled verification (Scope: Researcher test environment; active exploitation in the wild is unconfirmed).
• Information Theft or Session Compromise Confirmed: Public Information: Access to private source code and CI variables was demonstrated in the same tests (Scope: Access to data managed by researchers; theft confirmation from victim organizations is absent).

10. Investigation Playbook

The following are proposed investigation and mitigation measures based on public information.

Investigation Starting Point

• Start by looking for public exposure of incoming email addresses or unfamiliar email-initiated code modifications.

Initial Verification

• Check the token owner, exposure duration, associated projects, and operational permissions for protected branches.

Endpoints and Servers

• Preserve incoming emails, patches, job logs, and runner process records.

Authentication and Cloud

• Inventory CI variables, job tokens, and deployment credentials that the affected jobs could access.

Subsequent Operations

• Check for retrieval of private data, modifications to artifacts or deployment targets, and actions affecting other projects.

Containment

• Reset exposed tokens and stop unauthorized jobs. Investigate and revert alterations, and rotate any secrets that may have been accessed.

Decision Categories

• Evaluate address exposure, email acceptance, code modification, job execution, and data access separately.

11. Defense and Detection Ideas

The following are proposed investigation and mitigation measures based on public information.

Single Events

• Detect email-initiated branch modifications or CI configuration changes that lack standard modification workflows.

Time-Series Correlation

• Correlate incoming emails with pipeline triggers and outbound runner communications.

Threat Hunting

• Search for incoming email addresses mentioned in public sources and review multi-project operations performed by their owners.

Log Limitations

• Without incoming email and runner execution records, web authentication logs alone cannot determine the operational origin or data access.

Priority Mitigations

• Prioritize token resets, removal of exposure vectors, and minimization of project and CI permissions.

12. Facts, Inference, and Hypothesis

Facts

• Incoming email tokens are issued per user and shared across multiple projects belonging to that user. They do not expire until explicitly reset.
• Email senders are not validated; if the address is modified for a merge request and a patch is attached, branch creation and modifications occur under the token owner's permissions.
• Tokens do not exceed the existing permissions of the owner. Direct pushes to protected branches require the user to have push rights. Furthermore, GitLab incoming emails are exempt from group IP restrictions.
• Aikido demonstrated authorized changes to protected main branches and access to private source code and CI variables under controlled conditions. This report does not confirm actual attack victims.
• Aikido discovered approximately 12 valid addresses in public documents and other sources. GitLab reportedly considered this expected behavior and updated warning notices and documentation.

Inference

• Incoming email addresses must be managed as long-term credentials, requiring a joint review of exposure scopes across repositories, documents, and email archives, along with user permissions.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in open questions and further investigation.

13. MITRE ATT&CK Mapping

• T1552.001 Unsecured Credentials: Credentials In Files (Confidence: High): Mapping to the path demonstrated by researchers where credentials are obtained from public repositories or documents.
• T1078 Valid Accounts (Confidence: High): Mapping to the verified technique of leveraging the legitimate permissions of the token owner.

14. Open Questions and Further Investigation

• The presence of actual attack victims utilizing exposed tokens.
• Total exposure counts, revocation status, and affected project counts across GitLab.com and Self-Managed deployments.

15. Impact on SOCs and Organizations

Audit incoming email addresses across public documents, wikis, ticketing systems, and email archives, and reset any exposed tokens. While glimt- is a useful search clue, older formats and custom prefixes also exist, so do not rely solely on this string to conclude searches. Make email-initiated code modifications and CI executions subject to auditing.

16. Summary by Role

• SOC: Correlate incoming emails, branch modifications, pipelines, and outbound runner traffic on a unified timeline.
• Administrators: Reset exposed tokens and review user permissions, protected branches, CI secrets, and runner privileges.
• Users: Do not make incoming email addresses public. Report any exposures or unfamiliar modifications to administrators.

Comments

[Fenix]

que heavy! Gracias por todas tus publicaciones Anoymask, por la divulgacion.