Security & supply chain

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

GitLab'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

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
Security & supply chain

npm provenance attestations get worn as camouflage in a new worm-style attack

The New Stack reports a supply-chain campaign against npm that turned the exact control CI/CD teams have started to lean on into cover. Attestations do not become useless overnight, but reading them as a green light gets harder starting now.

August 12, 2026
Security & supply chain

CI is the wrong place to first hear about your npm dependencies

A DevOps.com essay argues dependency-security feedback that only arrives after a push and a pipeline run is structurally too late for Node projects, where transitive findings can outnumber direct ones. The diagnosis is right. The prescription deserves more scrutiny than the post gives it.

June 29, 2026

Turn this into your pipeline. Build it on Buddy.

Start free