GitLab generates private email addresses containing a 'glimt-' token that enables creating work items (issues, tasks) or merge requests via email. These addresses are tied to developer accounts and persist across similar addresses for a project. Researchers found multiple such addresses deliberately exposed in public documentation, which attackers can abuse to push code, open merge requests, or access sensitive project data depending on the associated account permissions. GitLab does not verify that the sender's email matches the token owner, allowing any email sender to use these addresses. The attack bypasses IP restrictions and requires knowledge of the project path and ID, which are public for public projects and brute-forceable for private ones if the path leaks. GitLab warns users to keep these addresses private and reset tokens if leaked. The issue was reported to GitLab, which closed it as intended behavior but improved UI and documentation to clarify security implications. Project maintainers should stop exposing these addresses and reset tokens if exposed.

Attackers who obtain exposed GitLab private email addresses can create issues or merge requests on projects as if they were the token owner. This can lead to unauthorized code changes, access to private repositories, exposure of secrets from CI/CD variables, and access to confidential issues. The level of impact depends on the permissions of the associated GitLab account. The attack bypasses IP restrictions and can affect both public and private projects if project identifiers are known or leaked. This creates supply-chain risks, especially for popular open-source projects that expose these addresses in public documentation.

GitLab advises users to keep private email addresses containing tokens confidential and to reset the token immediately if exposure is suspected. Project maintainers should remove these email addresses from public documentation such as READMEs and contributing guides. Tokens for any exposed projects should be reset to prevent unauthorized use. GitLab has updated its UI and documentation to clarify the risks but considers this behavior intended. No official patch changes the underlying mechanism, so mitigation relies on operational security and token management.