CICI/CD News
Security & supply chain

GitLab's per-user email token can push code and trigger pipelines

September 26, 2026gitlabci-cd-securitytokenssupply-chainaikido
Tomás Vega · Supply-chain security engineerGitLab's per-user email token can push code and trigger pipelines

Every GitLab user carries a credential most of them have never looked at. It sits inside a per-project email address, it can push code and run pipelines, and it does not expire. Aikido Security researcher Joe Leon disclosed this week, in reporting on DevOps.com, that if that address leaks an attacker gets a fine-grained personal access token in convenient email form.

The mechanic, per Leon's writeup: GitLab lets you create issues and merge requests by emailing a project. The token inside those private addresses is the same one across every project the user can reach. Change the suffix from "-issue" to "-merge-request", attach a .patch file, and you are submitting code as that user. Which means CI/CD runs. Which means CI_JOB_TOKEN. Which means whatever else that job can touch.

What the token actually unlocks

Leon lists the reachable surface as pushing patches, kicking off CI/CD pipelines, pulling private source, reading CI/CD variables and secrets, and pivoting to other GitLab resources via CI_JOB_TOKEN. Anywhere the account owner has access, the emailed token has access. GitLab's own documentation, quoted in the article, calls it "essentially a fine-grained personal access token with significant access to your GitLab projects." Read that sentence twice.

GitLab's response, and yours

GitLab has not turned the feature off. Aikido's HackerOne report in May was closed as intended behavior. A confidential issue followed in June. On July 28 GitLab opened a merge request updating the docs so the capability of the token is described more plainly. The interface got a clarification pass. That is the fix.

The user-side mitigation is one click: reset the token in personal access token settings and every previously issued project address dies with it. Do that on any account whose email has ever appeared in a leak, a screenshot, a stale CI log or a support ticket. Rotate on a schedule if you can stomach the churn.

A long-lived credential that grants pipeline write access, transmitted over email by design. Working as intended.

Source: DevOps.com (devops.com)

Related
Security & supply chain

GitLab Secrets Manager hits GA in 19.5 and scopes credentials to the job

GitLab Secrets Manager is generally available in GitLab 19.5 for Premium and Ultimate. Built on OpenBao, it hands a credential only to jobs that declare it and match its branch and environment scope, and every CI/CD read is logged with its pipeline and job ID.

October 20, 2026Security & supply chain

GitLab's Dependency Firewall moves package policy in front of the build

GitLab has put Dependency Firewall into early access, a policy layer that blocks malicious, vulnerable or non-compliant packages before they reach a build. It shifts dependency checks from after install to before it, which is where credential-stealing packages do their damage.

October 15, 2026Security & supply chain

One credential, three tools deep: the LiteLLM supply-chain breach

CloudSEK, in reporting picked up by devops.com, puts the LiteLLM incident at about 2,500 companies and 434,000 CI/CD pipelines. The route ran through a vulnerability scanner before it reached LiteLLM, which is where the number gets uncomfortable.

August 13, 2026

Turn this into your pipeline. Build it on Buddy.

Start free