GitLab Incoming Email Tokens Can Enable Code Pushes and Bypass IP Restrictions

Summary

Researchers found GitLab incoming-email tokens can enable account-wide code pushes, CI/CD execution, and access to private-project data, including by email despite IP restrictions. GitLab updated UI wording but left the mechanism unchanged.

Key points

Each incoming-email address contains a long-lived token shared across an account's project addresses; its reach depends on the owner's permissions.
Researchers tested a merge-request email with a patch that added a job to .gitlab-ci.yml, resulting in code being pushed and CI/CD running in a private project behind an IP allowlist.
The researchers also report testing paths to exfiltrate source code, read CI/CD variables and secrets, access confidential issues, and use CI_JOB_TOKEN to reach further into an account.
The risk depends on someone obtaining the address. The article says researchers found live addresses deliberately published in public documentation and support materials.
The article says all GitLab.com accounts are affected and self-managed instances are affected when incoming email is enabled; GitLab Dedicated does not appear to be affected.
Users cannot disable the feature, according to the article. Resetting the incoming-email token invalidates all of the owner's project addresses.
After the report, GitLab updated UI wording and documentation, but the article says the token mechanism remains unchanged and sender addresses are not verified.

Article Details

Attack Vectors: An attacker who obtains a user's incoming email address can submit email that GitLab processes as that user; the article reports that the sender address is not verified.
Replacing the address suffix `-issue` with `-merge-request` and emailing a `.patch` attachment can create a merge request that modifies a source branch, including `.gitlab-ci.yml`.
GitLab may push the change to an existing branch or create a branch, then run CI/CD jobs with the victim's permissions.
The incoming email token is account-wide rather than project-scoped, so the article reports that it can reach other projects the account can access.
The email path can bypass project IP restrictions that block browser and Git access.
The article reports tested paths involving code pushes, source-code and CI/CD secret access, confidential issues, and use of the available `CI_JOB_TOKEN` to reach further into the account.
Defensive Notes: Search repositories, documentation, help centers, and wikis for incoming email addresses, including `@incoming.gitlab.com` and the corresponding domain for self-hosted instances.
Reset a potentially exposed incoming email token from User settings > Personal access tokens > Incoming email token; the article says this invalidates all project addresses for that account.
Review recent commits, especially changes to `.gitlab-ci.yml`, and investigate pipeline runs the address owner does not recognize.
Use secret scanning that detects current and legacy GitLab incoming email token formats; the article names Betterleaks and Aikido's secrets detection.
The article says GitLab does not provide a setting to disable incoming email creation or require the sender to match a verified account address.