In the modern DevOps landscape, the convenience of platform integrations often introduces subtle, high-impact security surfaces. Security researchers at Aikido Security recently detailed an attack vector involving GitLab’s incoming email tokens—a feature designed to streamline collaboration by allowing users to create issues and merge requests directly via email. The findings, reported in September 2026, suggest that if these specialized email addresses are exposed, they can grant an unauthorized party the ability to execute code, manipulate CI/CD pipelines, and potentially exfiltrate sensitive secrets.
At the core of the issue is the nature of the incoming email token itself. GitLab provides these tokens to facilitate asynchronous workflow management. However, as Aikido Security researcher Joe Leon discovered, these tokens function effectively as fine-grained personal access tokens. Because they are tied to a user’s existing account permissions, any actor who obtains the token can perform actions with the same level of access as the account owner.
Crucially, Aikido found that these tokens are often reused across multiple projects associated with a single user. An attacker who gains access to one of these project-specific email addresses can manipulate the address suffix—shifting from ‘-issue’ to ‘-merge-request’—to initiate unauthorized code submissions. Because GitLab allows users to attach .patch files when creating merge requests via email, an attacker could theoretically inject malicious changes directly into the repository. If the target branch is protected, the attack scope remains limited to the user’s specific permissions; however, for users with Maintainer roles, this could permit the modification of sensitive configuration files, including the .gitlab-ci.yml pipeline definition.
The implications for CI/CD security are significant. By modifying the .gitlab-ci.yml file via an emailed patch, an attacker can trigger automated pipelines to run under the victim’s account. This creates a bridge to further exploitation, as the resulting CI/CD jobs can be used to read environment variables, access stored secrets, and utilize the CI_JOB_TOKEN to interact with other GitLab resources. Depending on the project’s security posture and the breadth of the victim’s access, this could lead to the exposure of private source code or the compromise of downstream development infrastructure.
While the attack does not constitute a privilege escalation—the attacker is inherently bound by the victim’s existing rights—it effectively weaponizes a collaboration feature for unauthorized automation. Reaching private resources requires the attacker to possess specific project paths and IDs, adding a layer of reconnaissance to the attack path.
GitLab’s response to the disclosure has centered on transparency and user control rather than deprecating the functionality. Following communications through the HackerOne platform and a subsequent confidential issue report in June 2026, GitLab updated its documentation and interface in late July to clarify the scope of these tokens. The company now explicitly warns that these credentials should be treated with the same level of security as personal access tokens.
For enterprise security teams, this development serves as a critical reminder of the risks associated with “shadow” access points within developer tools. Organizations should audit their use of email-to-GitLab integrations and ensure that developers understand the sensitivity of these generated addresses. Users who suspect that a token has been exposed should immediately reset it through their personal access token settings, which invalidates all previous addresses associated with that credential. As software supply chain security continues to move toward the gate, the protection of every identity-linked token—no matter how trivial its intended purpose—remains a fundamental pillar of resilient DevOps practice.
Source: DevOps.com
