Affected Systems
GitLab.com (all accounts) and self-managed GitLab instances with incoming email enabled (default). GitLab Dedicated appears unaffected. All user roles affected, with impact severity scaling to account permissions (Guest minimal, Maintainer critical).
Exploitation Status
No CVE assigned. GitLab considers this intended behavior, not a vulnerability. Aikido Security published proof-of-concept demonstrating commit injection and CI/CD job execution. Approximately a dozen live tokens found exposed in public repositories.
Business Impact
Leaked issue email tokens allow attackers to commit code to any branch the user can access (including main), execute CI/CD pipelines with user privileges, and access secrets available to that role. Attack bypasses IP allowlists and 2FA. Tokens do not expire and are shared across all projects for a given user. Risk highest for Maintainer/Owner accounts with access to protected branches and CI/CD variables. Supply chain risk if tokens from high-privilege accounts in open-source projects are exposed in documentation or support channels.
Urgency
🟡 Within a week
Recommended Actions
- Audit public repositories, READMEs, and support documentation for exposed GitLab issue email addresses containing incoming email tokens
- Reset incoming email tokens for all users from GitLab profile settings under personal access tokens (invalidates all project-specific addresses simultaneously)
- Review GitLab audit logs for unexpected commits or CI/CD job executions, filtering for email-originated merge requests
- For self-managed instances, consider disabling incoming email feature instance-wide if not operationally required
- Educate developers to never publish issue email addresses in public documentation or issue trackers