GitLab’s incoming email token – a credential embedded in the private email addresses used for creating issues and merge requests – can be leveraged to push code, start CI/CD pipelines, and read other projects that the token owner can access. Practitioners need to treat any exposure of these addresses as a direct path to execute actions with the victim’s existing GitLab permissions.
How the GitLab Email Token Works
The platform generates a unique token for each user’s incoming‑email address. The token never expires and, per GitLab documentation, anyone who knows it can create issues and merge requests on behalf of the user. The same token appears in addresses for all projects owned by that user, and the address suffix determines the operation (e.g., -issue for issues, -merge-request for merge requests). Users can also attach .patch files when sending merge‑request emails; GitLab will apply the patch to the specified branch or create the branch if needed.
Attack Path Demonstrated
Aikido Security showed that an attacker who obtains a single email address can modify the suffix from -issue to -merge-request, attach a patch, and submit code using the victim’s permissions. By sending a patch that adds a job to .gitlab-ci.yml, the attacker can trigger a pipeline that runs under the victim’s account. The same pipeline can read CI/CD variables, exfiltrate source code, and reuse the job’s CI_JOB_TOKEN to access additional GitLab resources permitted to that token. The attack is limited to the victim’s existing project permissions; a token tied to a Guest account offers little value, while a Maintainer token can expose protected branches and CI/CD secrets depending on configuration. Access to another project also requires knowledge of its path and ID – public projects expose this information, whereas private projects would need additional leaks.
Operational and Security Implications
Because the token does not elevate privileges, the risk is bounded by the user’s role, but the ability to inject code and run pipelines can still lead to credential leakage and supply‑chain compromise. Organizations that rely on email‑driven issue or merge‑request creation must treat the email address as a sensitive credential. GitLab’s response has been to clarify token capabilities and update documentation, but the underlying email functionality remains enabled.
- Exposure of an incoming‑email address effectively grants the same access as a personal access token for that user.
- Tokens are reusable across all of a user’s projects, amplifying the impact of a single leak.
- Pipeline execution via emailed patches can read CI/CD variables and propagate the victim’s
CI_JOB_TOKENto other resources. - Guest‑level tokens provide limited attack surface, while Maintainer‑level tokens can affect protected branches and secret variables.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Teams should audit any stored or shared incoming‑email addresses and treat them as high‑value credentials. If an address is suspected to be exposed, reset the associated token from the personal access token settings to invalidate all derived email addresses. Consider reducing reliance on email‑based workflows, especially for high‑privilege users, and implement monitoring for unexpected merge‑request emails or pipeline runs originating from email triggers. Updating internal documentation to highlight the non‑expiring nature of these tokens and enforcing strict handling procedures will mitigate the risk of accidental leakage.
