What happened
On 23 September 2026, Dark Reading reported Aikido Security’s tests of exposed GitLab incoming-email addresses and their cross-project authorisation impact. On 24 September 2026, BleepingComputer reported additional detail on public address exposure, protected-branch risk and source-IP restriction bypass. GitLab’s Email work item to this project feature generates a private address containing a long-lived token tied to the developer’s account. Aikido Security reported finding at least a dozen incoming email addresses exposed in public README, contribution and support material during a limited search.
Researcher testing indicated that an exposed address could be adjusted to target other projects, submit merge activity, reach private project functions and bypass configured source-IP restrictions. The cited reporting did not identify a CVE, affected version range, payload, malicious domain, IP address or hash. Attribution posture: The cited reporting describes researcher testing and exposed tokens; no malicious exploitation campaign has been established. The evidence therefore supports a credential-exposure and authorisation review, not a conclusion that every published address has been abused. The cited source did not publish the specific indicators described as No version, CVE or malicious infrastructure available.
Why this matters now
The security boundary is easy to misclassify because the credential is formatted as an email address and may have been intentionally published to simplify issue submission. If the embedded token inherits the user’s wider project rights, documentation hygiene becomes an identity and authorisation problem. Removing the visible string does not invalidate copies in search indexes, forks, caches, mailing lists or local clones. Exposed addresses should therefore enter the same response process as leaked API keys.
The supply-chain consequence comes from what the token may authorise, not from email delivery itself. Researcher testing described code changes against protected branches, access to private project functions and bypass of source-IP restrictions. Even without evidence of malicious exploitation, organisations should determine whether a compromised address could initiate merge activity, trigger CI workflows or expose project information under a trusted user’s identity.
The decision for security leaders
Assign the GitLab service owner and identity team to treat every exposed incoming address as a leaked credential. Discovery should cover public repositories, documentation sites, forks, ticketing systems, support pages, chat archives and internal knowledge bases. Invalidation must occur before content cleanup because removing the reference does not revoke copies already indexed or downloaded.
Assign application security to review the affected user’s project rights and the audit trail for email-created issues, merge requests, branch changes and CI execution. Where logs cannot establish whether the token was used, record the limitation and review downstream source, artefact and secret integrity. The decision should be risk-based, reflecting the user’s actual project and protected-branch authority.
Evidence of closure
- Discovery results show no active exposed GitLab incoming-email addresses.
- Token invalidation records cover every identified address.
- Audit review documents an approved disposition for associated project activity.
- Repository policy prohibits publishing credential-bearing project addresses.
The Security.io assessment
The demonstrated risk is a proof of concept rather than a confirmed attack campaign. No CVE, affected-version boundary or malicious infrastructure was published, and the original Aikido research was described through accountable reporting. Confidence is therefore medium. The absence of observed abuse should not be mistaken for low impact where an exposed address belongs to a maintainer, release engineer or user with access to private projects and CI secrets.
The control lesson is durable: secrets should be classified by authority and revocability, not by their visual format. An email-shaped token can be copied into documentation without triggering conventional secret scanners or reviewer concern. GitLab owners should add recognisable incoming-address patterns to secret discovery, establish a rapid invalidation procedure and ensure protected software changes require controls independent of the token-bearing user’s identity.
Questions for the morning meeting
- Are GitLab incoming project email addresses present in public repositories, documentation, tickets or support pages?
- Can the GitLab owner prove that exposed addresses have been invalidated rather than merely deleted from documents?
- Do audit logs distinguish email-created work items and merge activity from normal interactive use?