GitLab Email Token Lets Attackers Push Code to Main and Execute CI/CD Jobs
GitLab incoming email tokens can push code, open merge requests, and run CI/CD while bypassing IP allowlists.
Aikido Security researcher Joe Leon reported that GitLab incoming-email addresses for the Email work item feature embed a long-lived glimt token. The token does not expire, is reused across projects the account can access, and authenticates as the owner. An attacker who obtains it can email a Git patch to create branches or merge requests and, with enough permission, commit to main and change .gitlab-ci.yml so GitLab runs attacker-controlled CI/CD jobs that may expose variables or CI_JOB_TOKEN. Aikido showed this path bypasses IP allowlists; GitLab updated its documentation, but the non-expiring token remains, and no in-the-wild exploitation or CVE was reported.
- Non-expiring glimt tokens are reused across all of an owner's projects.
- Emailed Git patches can create branches, merge requests, or commits on main.
- A malicious .gitlab-ci.yml can run CI jobs and expose secrets or CI_JOB_TOKEN.
- Incoming email is excluded from GitLab IP allowlists.
- Reset leaked tokens and search repos for published incoming-email addresses.
- Vendors
- GitLab
- Products
- GitLab
- Organizations
- Aikido SecurityGitLab
From the original article
3 min read at gbhackers.com
A long-lived GitLab incoming email token embedded in project email addresses for the “Email work item” feature can be exploited to push attacker-controlled code, create merge requests, and trigger CI/CD pipelines using the permissions of the token owner. This issue can also bypass GitLab’s IP restrictions, as incoming email is explicitly excluded from those controls. […]
By Divya · gbhackers.com
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.