A Leaked GitLab Email Address Can Become a Code-Push Credential
A leaked project email address can become a code-push credential. Aikido researchers demonstrated that GitLab incoming-email tokens can authorise attached patches, commits and CI runs within the account owner’s permissions. This is a research finding, not evidence of an active attack campaign.
An email address with the authority of an account
Aikido found that the embedded token is reused across an account’s projects, has no expiry and does not validate the sender. In its test, email-driven code changes also bypassed a project IP allowlist. The attacker still needed project information and sufficient permissions on the victim account; possession does not grant unrestricted access to every branch.
GitLab’s documentation tells users to keep incoming addresses private and reset the token after a leak. Aikido says GitLab improved warnings and documentation after disclosure, while retaining the underlying behaviour.
The hidden credential belongs in your secret inventory
The practical problem is discoverability. A team may recognise a token in a configuration file as sensitive while treating an email address in a contribution guide as harmless contact information. Security review should follow the authority a value carries, not its appearance.
For maintainers, the question is what a compromised identity could change before a second person notices. Separate repository write access, pipeline execution and production deployment in that review. A successful commit should not automatically become permission to use every deployment secret.
What GitLab administrators and maintainers should do
- Search for incoming addresses. Scan repositories, history, wikis, documentation, tickets and help centres for
@incoming.gitlab.comor the self-managed incoming-email domain. - Treat a match as a leaked credential. Reset the owner’s incoming email token. Consult GitLab’s reset guidance and update dependent workflows.
- Review commits and pipelines. Examine recent changes attributed to the owner, especially modifications to
.gitlab-ci.yml, protected branches and unexpected pipeline runs. - Reduce maintainer-token impact. Use protected environments, scoped and short-lived CI secrets, separated runners and independent approval for production deployment.
- Do not rely on IP restrictions for this path. Include email ingestion in the threat model for projects that otherwise appear network-restricted.
- Change support workflows. Publish a normal support mailbox or issue form rather than the token-bearing incoming address.
BlackTree previously covered an unauthenticated GitLab flaw that could make public projects writable and an AI-agent path into CI commands. This is a different boundary: no software exploit is required if a credential-shaped email address has already been published.
Sources
- Aikido, original GitLab incoming-email research, published 23 September 2026 and updated 25 September 2026. The page provides no publication or update times.
- BleepingComputer, independent reporting, published 24 September 2026 at 13:47 as displayed. The page does not label the timezone.
- GitLab documentation, create an issue by email, accessed 25 September 2026. Documentation pages do not provide an article publication time.
