GitLab's Per-User Issue Email Is a Password in Disguise
The private address you use to file issues by email can also push code and start pipelines as you. Treat it like a credential, because it is one.
Key points
- Every GitLab user has a private email address for filing issues, and anyone who obtains it can email in code changes and start automated build jobs that run under that user's name.
- The address sits behind a button labelled "Email work item to this project" and isn't treated as a secret by most teams, yet it behaves like a login token.
- Multi-factor authentication does not protect this channel, because the email server accepts the address itself as proof of who you are.
- GitLab's own documentation lists email as a normal way to create merge requests, the requests to add new code to a project, alongside the web app and command line.
- Self-hosted admins can limit the damage by restricting Git access protocols and locking groups to specific IP ranges, but there's no per-user off switch for the email inbox itself.
GitLab hands every user a private email address for filing bug reports and change requests without opening a browser. Convenient. Also, as security researchers have been pointing out this week, a quiet way to act as someone else on a code project.
The address is visible inside GitLab behind a button called "Email work item to this project." Send a message to it and GitLab opens an issue in the project, with you listed as the author. That much is expected.
The uncomfortable part is what else the same channel accepts. Per GitLab's own guidance, users can create a merge request by sending an email, meaning a proposal to add new code into the project. A merge request can target any branch you have permission to push to, including the main branch that usually ships to production. It can also kick off CI/CD, the automated system that builds and deploys code, running with your permissions.
So the address isn't a mailbox. It's a bearer credential, a secret that grants access to whoever holds it, requiring neither a password nor a second factor.
How would an attacker actually get the address?
The address leaks the way small secrets always leak: in screenshots on Slack, a helpful blog post, a shared screen during a demo, or a support ticket with the full header pasted in. It's not classified inside most engineering teams, because nobody told them it should be.
Once someone has it, nothing on the receiving end checks who actually sent the mail. The service trusts the To: address as proof of identity. That's the whole authentication story here, and it's why MFA doesn't help. MFA, short for multi-factor authentication, protects logins. This path never touches a login.
Email's delivery standard makes it trivial to forge a From: address, so an attacker doesn't even need to control your mailbox. They just need the secret string. We've covered how static credentials become liabilities before: the Shai-Hulud worm story from 3 September is a useful companion read, showing how a credential thief works through developer machines hunting exactly this kind of overlooked secret.
What can defenders actually do today?
Treat the per-user issue address like an API key. Rotate it if you suspect exposure, keep it out of tickets and chat, and scrub it from screenshots before sharing.
Admins running GitLab Self-Managed or Dedicated have more levers. GitLab lets you restrict group access by IP address on Premium and Ultimate tiers, which blunts remote abuse of a leaked address. You can also limit Git access protocols at the group level. Yesterday's GitLab patch story is worth revisiting: self-hosted admins who haven't applied those fixes are carrying two separate exposure vectors right now.
Branch protection rules on main and other release branches remain the single most useful control. If merges require review from a second human, an emailed patch can't silently reach production, no matter who authored it.
The Hacker News flagged the behaviour this week, and the mechanics line up with GitLab's own documentation rather than any undisclosed bug. That's the part worth sitting with. This isn't a vulnerability with a CVE number attached. It's a design choice from an era when "email in a patch" felt friendly, colliding with a present where every string that grants write access to production code needs to be treated as one.
After a decade of watching identity systems get bolted onto features that predate them: any channel that accepts a static string as proof of identity, and can write to main, is a credential. Name it, inventory it, rotate it. Otherwise it'll show up in someone's incident report.
