A Leaked GitLab Issue Email Address Lets Anyone Push Code and Run CI Jobs as You
A leaked GitLab incoming-email token lets outsiders commit code and run CI jobs as the account owner.
Aikido Security reported that GitLab's incoming-email address is a non-expiring account token. Anyone who obtains it can email a patch that GitLab commits as the user on branches they can push, including main, and can start CI/CD jobs running as that user, bypassing IP allowlists and two-factor authentication. The same token applies across the user's projects; reach also requires the project path and numeric ID, and impact depends on role. GitLab described it as intended credential behavior, updated the warning text, and is only considering verified-sender checks. Aikido found about a dozen addresses published in project documentation.
- Non-expiring incoming-email token works across a user's projects
- Holders can commit patches, including to main, and start CI
- Incoming email bypasses IP allowlists and two-factor authentication
- GitLab treats it as intended behavior; sender checks are proposed
- Users can reset the token; admins can disable incoming email
- Vendors
- GitLab
- Products
- GitLab
- Organizations
- Aikido SecurityGitLab
From the original article
4 min read at thehackernews.com
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."
thehackernews.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.