GitLab's incoming email address is a non-expiring token that commits code and runs CI as you
Aikido Security showed that the personal address GitLab issues for creating issues by email can also open merge requests that GitLab commits in your name and can start CI jobs, with no expiry and no MFA. GitLab calls it intended behavior.
Aikido Security disclosed on September 23 that the private email address GitLab gives each user for creating issues by email works as a credential. Changing the address suffix from -issue to -merge-request lets anyone who knows it email a patch that GitLab commits in the user's name, to any branch that user can push to, including main, and start CI/CD jobs that run as them. The token behind the address does not expire, covers every project the account can open, and bypasses IP restrictions and two-factor authentication, because GitLab does not check who sent the email. It affects GitLab.com and self-managed instances with incoming email configured. Aikido reported it through HackerOne in May; GitLab closed it as intended behavior, updated its documentation, and opened an issue to consider sender verification. Users can reset the token from their access tokens page; administrators can disable incoming email instance-wide.
Why it matters
Most token inventories would miss this one because it does not look like a token. It looks like an email address, which is exactly why people paste it into READMEs, support tickets and wiki pages to make "email us to open an issue" work. It is a bearer credential with write access to every project the user can reach, no expiry, and no second factor, so it belongs in the same inventory and rotation process as personal access tokens and deploy keys. See static API key abuse.
Two checks this week. Search your public documentation and ticket systems for GitLab incoming email addresses, and reset the token for any account whose address has ever been shared. Then look at branch protection: requiring an approved merge request limits which branches a mailed patch can land on, but it does nothing about the CI jobs that run as the user, which is where secrets live. This is the same shape as coding agents reaching CI secrets through a GitHub issue: an input channel nobody classified as an authentication path. See secrets in repositories and CI.
Source: The Hacker News
Related on Start with Identity
- BlogA hijacked AI coding assistant session spread Shai-Hulud to about 100 internal repositories
Mandiant describes an intrusion at an unnamed SaaS provider where a poisoned package, recommended through a developer's AI coding assistant session, led to stol
- BlogCrowdSec kept a departing engineer's GitHub access open, and lost 170 private repositories through it
An engineer's laptop was infected in the May TanStack npm attack. Eleven days later his still-active GitHub OAuth token was used to copy about 170 of CrowdSec's
- BlogThe Shai-Hulud worm now hunts 469 credential locations, up from 189
GitGuardian found the latest Shai-Hulud variant scanning 469 paths for secrets across developer machines, CI/CD, cloud config, and AI tool settings. The npm wor
- CVEKeycloak reset-credentials flow skips the email token, full account takeover
Improper state validation in Keycloak's reset-credentials authentication flow let an unauthenticated attacker jump straight to the password-update step, no emai
- GlossaryAccess Token
A short-lived credential a client presents to a resource server to access protected data. Access tokens are typically opaque or JWT-formatted, with lifetimes me
- GuideAuthentication vs Authorization: The Difference That Trips Everyone Up
Authentication and authorization sound alike and are often shortened to the same "authZ/authN," but they answer different questions. Getting them straight is fo