GitLab Email Token Flaw Could Let Bad Actors Inject Code and Trigger Pipelines

Security researchers have uncovered a vulnerability in GitLab's "Email work item" feature that could allow threat actors to push malicious code, open merge requests and start CI/CD jobs using the privileges of the token owner.

The feature assigns a unique, long‑lived token to each project’s inbound email address, enabling users to interact with a repository by sending specially formatted emails. The token is embedded directly in the address and is not routinely rotated, making it a persistent authentication credential.

According to the disclosure, an attacker who obtains the token—through publicly visible logs, repository history or misconfigured integrations—can craft an email that mimics a git push. The message can create a new branch, add files, and open a merge request targeting the main branch. Because the token inherits the project permissions of its owner, the malicious code can be merged and subsequently compiled or deployed by any configured CI/CD pipeline.

If exploited, the flaw opens a supply‑chain attack vector. Malicious code introduced via this route runs with the same trust level as legitimate commits, potentially leaking secrets, installing backdoors or compromising downstream environments that automatically deploy from the affected repository.

Both self‑hosted GitLab instances and GitLab.com customers could be affected, as the email token mechanism is part of the core product. The vulnerability is especially concerning for organizations that rely on email‑driven workflows for issue tracking or code reviews, a practice that remains common in legacy environments.

GitLab has acknowledged the issue and issued an advisory recommending immediate rotation of all incoming email tokens and, where feasible, disabling the email work item feature until a patch is applied. The company also plans to introduce shorter token lifetimes and more granular permission controls in upcoming releases.

Administrators are urged to audit existing project email addresses, revoke any tokens that have been exposed, and monitor inbound email activity for anomalous patterns. Implementing network‑level restrictions on who can send to the project‑specific email address can further reduce risk.

The discovery underscores a broader industry shift away from email‑based code integration toward more secure, token‑based APIs and webhook mechanisms. As supply‑chain attacks become more prevalent, vendors are tightening credential management and encouraging best practices such as regular token rotation and least‑privilege access.

GitLab’s forthcoming update is expected to address the root cause by making email tokens short‑lived and revocable on demand. Security teams will be watching closely for any signs of active exploitation, while developers consider alternative workflows that minimize reliance on long‑standing credentials embedded in email addresses.