GitLab email tokens enable unauthenticated commits and CI execution across all user projects

The token embedded in each project's issue email address is identical across all repositories tied to the account and carries the full permissions of the owner. Aikido Security demonstrated that changing the suffix from -issue to -merge-request and attaching a patch results in GitLab applying the diff directly to the named branch, including main, and executing any updated .gitlab-ci.yml jobs under the victim's identity. No mailbox access or sender verification is required. GitLab documentation explicitly states that incoming email features ignore IP restrictions and 2FA requirements, creating a direct path around controls that apply to browser and git operations. Public projects expose their numeric ID and path, making the attack trivial; private projects require only an additional identifier leak because IDs are sequential and guessable. The token grants only the victim's existing role, limiting impact for Guests while enabling Maintainer-level branch and secret access. This pattern reveals a recurring design flaw: features intended for convenience are granted implicit trust that overrides hardening mechanisms. Similar bypasses have appeared in other platforms when email or webhook ingestion paths were not subjected to the same authentication model as direct API calls. Resetting the token from the personal access tokens page invalidates every address at once, but organizations relying on published addresses for external reports must reissue and redistribute them. GitLab has not indicated plans to scope tokens per project or require sender verification. Self-managed instances with incoming email enabled remain exposed by default; GitLab Dedicated appears unaffected but untested at scale.