A leaked GitLab work-item email lets anyone open merge requests in your name
On September 24, 2026, Aikido revealed that GitLab’s “Email work item to this project” addresses, generated with a long-lived token and accidentally published in READMEs, let an attacker open merge requests or push code as the token owner. Search your repositories for these addresses and reset the exposed tokens.
May 2026. Aikido reports to GitLab, via HackerOne, that the “Email work item to this project” addresses contain a token that can be used as an identity. June 2026. GitLab first closes the report as “intended behavior,” then updates its UI after a second report. September 24, 2026. Aikido goes public after finding a dozen live addresses in public READMEs in a single afternoon. Why it matters: the secret does not leak through a misconfiguration — it is pasted in plain text into documentation, and it opens the door to repositories.
A token hidden inside an email address
GitLab ships a feature called “Email work item to this project”: it generates a private email address that, when it receives a message, turns it into a ticket or task in the project. That address is not just an address. It contains a string prefixed glimt- that acts as a long-lived token, tied to the account of the developer who generated it.
The token is persistent: it stays valid for every similar address created for the same project. And the feature is built to accept mail from any mailbox: GitLab processes the message as if it came from the token owner, without checking the sender address. “Any mailbox on the internet can send to that address, and GitLab processes the message as the token’s owner,” Aikido summarizes.
The root cause is architectural: the email channel was designed as a convenience, not an authenticated surface. A message arriving over SMTP is attributed by the destination address alone, so GitLab cannot distinguish the legitimate owner from an attacker who obtained the address. Every other credential path — web session, personal access token, SSH key — carries a second factor or a revocable secret. The work-item email carries only the address, and the address is the secret.
From issue to merge request, with a suffix
The exploit is disarmingly simple. An address of this kind ends with the suffix -issue. Change that suffix to -merge-request, and GitLab opens a merge request on the project, still in the name of the token owner. Aikido’s tests also show that the attack bypasses IP restrictions: the message arrives over the email channel, outside the normal authentication path.
The level of access depends on the account’s permissions. For a maintainer, that can mean code changes, triggering CI/CD pipelines, reading secrets from integration variables, or reaching confidential issues and the source code of a private repository. Two conditions remain: the project’s path and its ID. For a public project, both are public; for a private project, the ID can be brute-forced, but the path must leak — often through the same documentation that exposes the address.
GitLab’s own documentation does not mince words: the address is “generated just for you,” and the warning is unambiguous. “Keep it to yourself, because anyone who knows it can create issues or merge requests as if they were you. If you suspect this private email address was leaked, reset the token immediately.”
Addresses pasted into READMEs on purpose
The problem is not a GitLab bug: it is the voluntary exposure of the secret by maintainers. Aikido found, in a single afternoon, a dozen live incoming addresses in public READMEs, contributing guides, and support pages. They had been placed there deliberately, to let users send bug reports to maintainers.
The risk is all the heavier because the exposure sometimes touches very popular open-source projects. “A few belonged to very popular open source projects,” the researchers note. For an attacker, such an address on a widely used repository is a supply chain vector: push a malicious change through a merge request in the name of a maintainer, into a project that thousands of dependencies consume.
The exposure carries a multiplier when it lands in popular open source. A maintainer who pastes their incoming address into a README is not just handing an attacker access to one project — they are handing a token that can open merge requests in a codebase consumed by thousands of downstream dependencies. A malicious change merged under a maintainer’s name is the classic supply chain entry point, and it arrives without breaking any authentication control, because the email channel was never part of one.
GitLab’s response: “intended” behavior
Aikido reported the issue to GitLab through HackerOne in May. The initial answer: the report was closed as “intended behavior.” A second report in June eventually convinced the vendor to act, but on form more than substance: the UI now mentions merge requests, the inaccurate statements about token data access were removed, and the documentation now acknowledges that incoming mail bypasses IP restrictions.
The substance did not change: a leaked address stays usable until it is reset, and sender-address verification still does not exist — GitLab only says it is “considering” it. That is the core of the verdict: mitigation will not come from an automatic fix, but from a secret hygiene that teams must apply themselves.
Why this token is so hard to rotate
The trap of the “Email work item” address lies in its nature: the glimt- token is not a secret kept in a vault, it is an email address identifier. You do not revoke it like an API key; you find it pasted into documentation files, where nobody thinks to look for a secret. Rotation is manual, project by project, and every address published in a historical README stays usable until someone explicitly resets the token.
There is a second, subtler trap: persistence. “The token persists across all similar addresses generated for the project,” Aikido notes. In other words, resetting one address does not necessarily cut every route if other variants were generated for the same project. The only clean strategy is to inventory all of the project’s addresses and reset them in one pass.
Finally, the IP restriction bypass makes it worse. Many teams believe an IP allowlist protects their repositories from this kind of abuse. Aikido’s tests show the opposite: incoming mail bypasses that barrier, because it does not travel the normal authentication channel but the email path, handled “as the token’s owner.”
Verdict
If you maintain a GitLab project, search now for any incoming address in your READMEs, guides, and support pages — a grep -R "glimt-" . or a search for the -issue suffix in the repository is enough to find them — then reset the token on every exposed address. If you published such an address in the past, assume it has been collected: reset it and never republish it. If you want to collect bug reports, prefer a form, a public issue channel, or a dedicated address without a project token: the convenience of an email address is not worth the identity it carries. Treat the work-item address like any other credential: short-lived, rotated, and kept out of public files.