노출된 GitLab 수신 이메일 토큰은 무단 코드 수정 및 CI 실행을 허용합니다

1. Overview

• Original Title: Send GitLab an email, push to main
• Source: Aikido Security
• Published: 2026-09-23
• Updated: 2026-09-25
• Collected: 2026-09-25T08:28:50+09:00
• Severity: High
• Severity Basis: Aikido demonstrated in a controlled test that code modification, CI execution, and access to private data are possible. While active exploitation in the wild has not been reported, the severity is rated high because long-lived token exposure impacts the development infrastructure.
• Original: Send GitLab an email, push to main
• Related Sources: BleepingComputer: Exposed GitLab project email addresses let attackers push code, GitLab: Group access and permissions, GitLab: Incoming email token, GitLab: Create an issue by sending an email
• CVE: None
• Target Products and Services: GitLab, GitLab incoming email, GitLab CI/CD
• Update Reason: Clarified the distinction between overall dedicated destination addresses, internal incoming email tokens, sender and registered email addresses, the mechanism specifying actions via destination identifiers, the relationship from address exposure to token exploitation, and the impact of resets. Updated dates and GitLab official supplementary materials are also reflected.

2. Quick Summary

Dedicated destination addresses for creating GitLab issues and merge requests contain an incoming email token that authenticates the user. If this address is exposed, the token is exposed as well, potentially allowing a third party to modify code and run CI jobs within the owner’s existing permissions and project settings.

3. Attack Flow

This mechanism is described based on public information. The distinction between researcher verification, implementation analysis, and actual exploitation is described in “Attack Success Judgment”.

Relationship Between Dedicated Destination Address and Token

The issue in this case involves the dedicated destination address issued by GitLab for creating issues and merge requests, which is distinct from the email address a user normally uses.

Below is an explanatory example using the format shown in the original article. project-id and XXXX are not actual values.

[email protected]

Enter fullscreen mode Exit fullscreen mode

Term What it Refers to and Role Dedicated Destination Address The entire string above. It includes the target project, authentication token, and requested action. Incoming Email Token The glimt-XXXX portion above. This is a secret used by GitLab to authenticate the user. Sender and Registered Email Address The sender address is the email From header, while the registered email address is the address the token owner registered with GitLab. This is separate from the token included in the destination.

Exposing the dedicated destination address also exposes the token within it. While the full address varies by project, the token portion is shared for the same user.

From Exposed Dedicated Destination Address to Code Modification

1. A third party discovers a valid dedicated destination address in public documentation or elsewhere, obtaining the incoming email token and target project information contained within it.
2. In the dedicated destination address, the identifier immediately preceding the @ indicates the requested action. The attacker changes -issue to -merge-request without altering the token portion and sends an email with an attached Git patch. GitLab does not require the sender address to match the registered email address of the token owner.
3. GitLab processes branch creation or modifications under the permissions of the token owner. This is not a privilege escalation to projects or operations not permitted to the owner.
4. When 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 Location

• The attacker is in a position to send emails to GitLab’s incoming email feature, having obtained an exposed dedicated destination address or a valid incoming email token and target project information to construct the destination.
• Operations within GitLab are performed with the permissions of the token owner, while processes within jobs are executed with the permissions assigned to the runner and the job.

5. Victim and Administrator Perspective

Victim

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

Administrator

• Even without web login anomalies, email reception timestamps may correspond with code modifications and CI execution logs.

6. Success and Failure Conditions

Success Conditions

• The incoming email feature is enabled, and the exposed token has not been revoked.
• The token owner has the necessary operating permissions in the target project, and the request meets the email processing conditions.
• Impact via CI requires target job execution conditions as well as permissions for secrets and external resources.

Failure Conditions and Risk Mitigation

• Reset the exposed incoming email token. This invalidates all existing dedicated destination addresses containing the same token across all projects for that user. For legitimate integrations, update the destination with the new token.
• Reduce unnecessary project permissions and direct push permissions to protected branches, and restrict CI secrets and runner permissions to the necessary scope.
• For GitLab Self-Managed, consider disabling the unnecessary incoming email feature. Web or SSH IP restrictions alone cannot block the email path.

7. What Happens Upon Success

• 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 leaked from a dedicated destination address of one project can potentially be abused with existing permissions in other projects accessible by the same user. Operations on other projects require specifying the destination containing that project’s path and ID.

8. Observable Logs

This section includes perspectives for investigation and detection within your organization. It does not imply that all items were observed in public incidents.

Email

• Preserve the dedicated destination address of the incoming email, the sender address, the attached patch, and the processing results. Do not assume normal operation based solely on the sender display. Because the destination contains an authentication token, restrict the viewing and sharing scope of the preserved records.

Proxy, SWG, and DNS

• Check for suspicious external communications from runners. Web access logs alone cannot track email-initiated operations.

Endpoints and EDR

• Investigate runner jobs, child processes, artifact creation, and external transmissions.

Authentication and IdP

• Check token reset timestamps and changes to owner permissions and group memberships.

SaaS and Cloud

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

Network

• Correlate email reception timestamps with external communications from jobs.

9. Attack Success Judgment

Scope Confirmable from Public Information

• Initial Execution Confirmed: Public information: Code modification and CI execution were confirmed in Aikido’s controlled verification. (Scope: Researcher’s test environment. Active exploitation in real environments is unconfirmed.)
• Information Theft or Session Compromise Confirmed: Public information: Access to private source code and CI variables was demonstrated in the same verification. (Scope: Access to data managed by the researcher. This is not confirmation of theft from a victim organization.)

10. Investigation Playbook

Below are investigation and mitigation recommendations based on public information.

Investigation Starting Point

• Start from the exposure of dedicated destination addresses or unfamiliar email-initiated code changes.

Initial Verification

• Check the token owner, exposure duration, accessible projects, and operating 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 accessible by the affected job.

Subsequent Operations

• Check for acquisition of private data, modifications to artifacts or deployment targets, and operations on other projects.

Containment

• Reset exposed tokens and stop malicious jobs. Investigate and revert modifications, and update any secrets that may have been accessed.

Decision Categories

• Judge dedicated destination address exposure (internal token leakage), email acceptance, code modification, job execution, and data acquisition separately.

11. Defense and Detection Ideas

The following investigation and mitigation recommendations are based on public information.

Single Events

• Detect email-initiated branch changes or CI configuration changes that lack normal change procedures.

Timeline Correlation

• Correlate events from incoming emails to pipeline triggers and runner outbound communications.

Threat Hunting

• Search for dedicated destination addresses in public documentation, and investigate the owner of the token contained within them and that owner’s operations across multiple projects. While glimt- is a search clue, do not end searches with this string alone, as older formats and custom prefixes exist.

Log Limitations

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

Priority Mitigations

• Reset exposed tokens and remove dedicated destination addresses from public locations. Simply removing them from public locations does not invalidate tokens that have already been acquired. Minimizing project and CI permissions is also a priority.

12. Facts / Inference / Hypothesis

Facts

• Dedicated destination addresses for creating GitLab issues and merge requests contain an incoming email token that authenticates the user. Exposing a dedicated destination address also exposes this authentication token.
• While the entire dedicated destination address varies by project, the embedded incoming email token is shared per user. Tokens do not expire automatically; they remain valid until reset.
• GitLab does not require the sender address (From) to match the registered email address of the token owner. If a dedicated destination address is modified for merge requests and a patch is attached, branch creation or modification occurs under the token owner’s permissions.
• Tokens do not exceed the owner’s existing permissions. Direct pushes to protected branches require the user to have push permissions. Meanwhile, GitLab incoming emails are exempt from group IP restrictions.
• Aikido demonstrated changes to protected main, access to private source code, and CI variables under controlled conditions. This is not a report confirming actual attack damage.
• Aikido discovered approximately 12 valid dedicated destination addresses in public documentation and other sources. GitLab considered this intended behavior and reportedly updated warning notices and documentation.
• Resetting an incoming email token invalidates existing dedicated destination addresses containing the old token across all projects for that user.

Inference

• Because dedicated destination addresses contain long-lived authentication tokens, the entire address must be treated as sensitive information. Not only the exposure scope, but also the project permissions held by the token owner should be reviewed accordingly.

Hypothesis

No additional hypotheses. Unverified items are listed in “Unknowns and Further Investigation”.

13. MITRE ATT&CK Mapping

ID Technique Confidence Basis T1552.001 Unsecured Credentials: Credentials In Files high Aikido verification: Mapping to the path demonstrated by researchers where credentials are obtained from public repositories or documentation. T1078 Valid Accounts high Aikido verification: Mapping to the verified technique of utilizing legitimate permissions of the token owner.

14. Unknowns and Further Investigation

• Presence or absence of actual attack damage utilizing exposed tokens.
• Total number of exposures, revocation status, and number of affected projects across GitLab.com and Self-Managed.

15. Impact on SOCs and Organizations

Email addresses are generally treated as shared contact information, but this dedicated destination address contains an authentication token used to perform operations with the user’s permissions. An operational pitfall is that even publishing it as an issue reception point can impact other projects using the same token. Organizations using GitLab’s incoming email feature must treat this destination as managed sensitive data and investigate the impact scope per user when exposure occurs. Additionally, because group IP restrictions do not block email pathways, it is important to be able to track email-initiated code changes and CI executions in addition to monitoring web authentication.

16. Summary by Persona

• SOC: Review incoming emails, branch changes, pipelines, and runner outbound communications within a unified timeline.
• Administrators: Reset exposed tokens and review user permissions, protected branches, CI secrets, and runner permissions.
• Users: Do not publish dedicated destination addresses containing tokens. Treat them separately from regular contact information and report exposures or unfamiliar changes to administrators.