There is a credential in your public GitLab documentation. It never expires. It does not rotate. Any developer, researcher, or threat actor who reads your README can find it. And with a one-character suffix change to the email address, they can use it to push a commit directly to your main branch.
GitLab’s incoming email feature exists for a legitimate purpose. Project maintainers share an incoming email address so contributors can create issues by email without needing a GitLab account. That address contains the glimt- authentication token. The problem is that this same token, at the account level, also grants the ability to deliver .patch files that GitLab applies to any branch in any repository the account can access, including branches that are otherwise protected.
The sender does not need to authenticate with GitLab’s web interface. They do not need to know the account holder’s password. They do not need to pass multi-factor authentication. They only need the email address, which most development teams publish in their public-facing documentation by design.
In May 2026, a security researcher submitted this to GitLab via HackerOne. GitLab closed the report as intended behavior. A second submission followed in June 2026. GitLab’s response: documentation updates and interface text changes. The underlying mechanism is unchanged.
| 28.65M new hardcoded secrets added to public GitHub commits in 2025, a 34% increase year over year | 64% of credentials valid in 2022 were still valid four years later | None sender verification required before a .patch attachment is applied as a commit | Never expires: the token stays active until manually reset in user settings |
| KEY FACTS: THE GITLAB INCOMING EMAIL TOKEN ATTACK PATH The glimt- string in every GitLab project’s incoming email address is an account-level authentication token, not a project-scoped token, despite the address format implying otherwise. The token never expires and has no automatic rotation. Revocation requires a manual reset in User Settings > Personal Access Tokens > Incoming Email Token. Changing the email suffix from -issue@ to -merge-request@ enables .patch file delivery. GitLab applies the patch as a commit to the branch named in the email subject, including protected branches. There is no sender verification. Any mail server can send from any From address and be authenticated as the token owner’s account. GitLab confirmed this is intended behavior (May 2026, HackerOne). Only documentation and interface text were updated. The attack path is unpatched. |
The Token in the Address
The incoming email address format for every GitLab project follows this structure:
GitLab incoming email address formatincoming+<project-name>-<project-id>-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com |
The glimt- segment is the authentication token for the incoming email feature. Despite being embedded in a project-specific address, the token operates at the account level. It is not scoped to the project whose name appears earlier in the address. A single glimt- token authenticates actions across every repository the account owner can access.
Most documentation presenting this feature describes it as a convenience for issue creation. The UI label reads ‘incoming email.’ The address format includes a specific project name. Neither the interface nor the default GitLab documentation makes clear that the token in this address carries account-wide scope with permissions that go significantly beyond creating issues.
The token has no expiry date and no automatic rotation mechanism. The only way to invalidate it is a manual reset under User Settings, in the Personal Access Tokens section, under Incoming Email Token. Until that reset occurs, anyone who holds the address holds the token.
The Attack Chain: From README to Commit on Main
The attack chain requires no exploitation of a software vulnerability. It is a sequence of legitimate GitLab operations triggered by a credential that most teams have published without understanding what it grants.
// Status: No CVE assigned. GitLab confirmed intended behavior (May 2026, HackerOne). |
What the Token Grants
The incoming email token inherits the full permission set of the account it belongs to across all repositories that account can access. The table below reflects the confirmed scope, based on GitLab’s own documentation.
| Permission | Scope and Impact |
| Push to protected branches | All repositories accessible to the account, including private repositories. Protected branch rules configured in GitLab do not block commits delivered via the email mechanism. |
| CI/CD job execution | Any pipeline triggered by a commit to a branch the token can push to. If the delivered patch modifies .gitlab-ci.yml, the pipeline runs with the account owner’s permissions. |
| IP allowlist bypass | The account’s IP allowlist restrictions do not apply to commits delivered via the incoming email mechanism. Organizations relying on IP allowlisting as a control cannot block this path through network policy alone. |
| Confidential issue read | All confidential issues across all projects accessible to the account. The token’s account-level scope means project-level access controls do not limit confidential issue visibility. |
| CI/CD variables and secrets | All CI/CD environment variables and secrets accessible to pipelines under the account. A malicious .gitlab-ci.yml commit that triggers a pipeline can exfiltrate these values through pipeline output or an outbound HTTP call. |
GitLab’s Response: Intended Behavior
The timeline of how this issue has been handled is relevant to any security team assessing how to prioritize it.
| Date | Event |
| May 2026 | Security researcher submits HackerOne report documenting the glimt- token account scope and the -merge-request@ suffix attack chain. GitLab reviews and closes the report as ‘intended behavior.’ |
| June 2026 | Second HackerOne report submitted. GitLab responds by updating documentation and interface text to better describe the token’s scope. The underlying mechanism remains unchanged. |
| September 2026 | Independent security researchs confirms live, valid incoming email addresses in public repositories across multiple organizations. Researchers locate a dozen in a single afternoon of searching READMEs, contributing guides, and support documentation. Most were published deliberately. |
| September 2026 (same month) | CVE-2026-85706 disclosed: a path traversal vulnerability in the GitLab repository commits API, CVSS 10.0, unauthenticated arbitrary file read. Fixed in GitLab 19.3.2, 19.2.6, and 19.1.8 within one week of disclosure. |
| CVSS 10.0 Was Patched in a Week. This Has No CVSS and Is Still Open. CVE-2026-85706 received a CVSS 10.0 score, a patch across three release branches, and a remediation window of approximately one week from disclosure to fix. The GitLab incoming email token attack path has no CVE, no patch, and no remediation timeline from the vendor. The distinction is not a commentary on severity. It is a structural observation about how security programs prioritize: a CVSS score triggers patch cycles; the absence of one does not. The incoming email token attack path does not appear in vulnerability databases. It does not generate a CVE alert in your vulnerability management queue. It is the type of exposure that surfaces only through external attack surface monitoring of your own public-facing assets. |
How Widely Distributed Is This Credential?
The attack path described above requires one prerequisite: access to the incoming email address. That prerequisite is commonly met before the attack begins.
Researchers found a dozen live, valid incoming email addresses in a single afternoon of searching across public README files, contributing guides, and support documentation pages. Most of those addresses had been published deliberately. The teams maintaining those repositories shared the address to make the issue-by-email workflow accessible to external contributors.
This is the core exposure problem. The credential is not in a location where it should not be. It is in the documentation that is designed to be publicly shared. A developer who follows GitLab’s guidance and includes the incoming email address in their README has not made an error in their own understanding of the feature. They have published an account-level credential without being informed that this is what they were doing.
The address format reinforces the misunderstanding. The presence of a project name and project ID implies project-level scope. The feature’s label in the GitLab interface reads ‘incoming email,’ suggesting a narrow mail-to-issue utility. Neither signal communicates that the glimt- segment authenticates account-wide actions including protected branch commits and CI/CD pipeline execution.
What to Do Right Now
Reset the Incoming Email Token
- Navigate to your GitLab user settings. Open the Personal Access Tokens section and locate the Incoming Email Token entry. Click Reset. This immediately invalidates all previously distributed incoming email addresses for the account.
- After resetting, notify any teams or contributors who were using the email-to-issue workflow that the address has changed. The new address with the updated token will be available in the same settings location.
Audit Recent Repository Activity
- Review the git log for each repository accessible to the account for commits delivered via the email merge request mechanism. Look for commits that do not correspond to known developer activity, particularly any changes to .gitlab-ci.yml or other CI/CD pipeline configuration files.
- Review CI/CD pipeline execution logs for job runs triggered by unexpected commits. Pay particular attention to pipelines that accessed environment variables or secrets, and to any pipeline with outbound HTTP calls to external addresses not in your known integration list.
- If any commits or pipeline runs cannot be attributed to known team activity, treat the affected pipeline environment as potentially compromised. Rotate all CI/CD secrets and environment variables in scope for any pipeline that ran under suspicious conditions.
Update Documentation and Internal Guidance
- Remove incoming email addresses from all public-facing documentation, including READMEs, contributing guides, and support pages. If the email-to-issue workflow is needed, distribute the incoming email address through authenticated internal channels to individual contributors rather than publishing it publicly.
- Brief developers that the glimt- string in any GitLab incoming email address is an account-level credential. Any existing internal guidance recommending that teams share this address publicly should be treated as outdated. The GitLab interface may not yet reflect this clearly; supplement it with team-level communication.
Brandefense Coverage for This Exposure Class
The GitLab incoming email token represents exactly the exposure class that traditional vulnerability management is not equipped to find: no CVE, no CVSS score, no patch to apply, and no alert from your existing tooling. The exposure lives in your public documentation. Finding it requires continuous visibility into what your external-facing assets actually contain.
| Brandefense Capability | Coverage for Developer Credential Exposure |
| Security Findings / DISCLOSURE (/attack-surface/security-findings) | The Security Findings module’s DISCLOSURE category surfaces credentials, tokens, and sensitive identifiers found in external-facing organizational assets. Public-facing repositories, documentation pages, and support sites that contain GitLab incoming email addresses with embedded glimt- tokens are flagged as DISCLOSURE findings, with severity classification and a Solution block that maps directly to the remediation steps above. |
| Entity Discovery (/attack-surface/entities) | Continuously discovers and inventories external-facing domains, web properties, and documentation assets associated with the organization. The Web Sites table captures public documentation pages, developer portals, and support sites, giving the Security Findings module the scope it needs to identify where developer credentials are publicly exposed. This includes assets from subsidiaries and acquired entities that may not be in the central inventory. |
| Vulnerability Intelligence (/modules/vulnerability-intelligence) | Tracks CVE-2026-85706 and all other active GitLab CVEs through the Vulnerability DB, mapping them to discovered organizational GitLab assets using Priority Score context that combines CVSS, EPSS, KEV listing status, exploit availability, and community activity signals. Organizations running GitLab 19.3.1 or earlier are surfaced as exposed to CVE-2026-85706 independently of the email token issue, ensuring both the patched and unpatched exposure classes are covered in the same workflow. |
| Security Findings / MISCONFIGURATION | CI/CD configuration files and pipeline definitions exposed through public repository visibility surface as MISCONFIGURATION findings. This provides additional context for security teams assessing the blast radius of an email token exposure: a repository with a publicly visible .gitlab-ci.yml that handles secrets is a higher-priority remediation target than one without. |
RELATED READING
API Sprawl: The Attack Surface Nobody Put On the Inventory : how ungoverned API endpoints create the same persistent access risk as a published glimt- token, and why both require continuous external discovery to surface https://brandefense.io/blog/api-sprawl-shadow-zombie-api-attack-surface/
Your Identity Programme Was Built for People. Non-Human Identity Is Now the Leading Way In. : the broader pattern behind the glimt- exposure: non-human credentials accumulate in documentation and configuration files with no rotation, no expiry, and no visibility in standard IAM reviews https://brandefense.io/blog/non-human-identity-leading-entry-point/
Shadow IT: Why the Assets Your IT Team Doesn’t Know About Are Your Most Dangerous Entry Points : public-facing developer documentation follows the same risk model as unmanaged shadow IT: it exists outside the monitored perimeter, and credentials embedded in it are invisible to tools that don’t scan it https://brandefense.io/blog/shadow-it-hidden-attack-surface/
When Abandoned Digital Assets Become Someone Else’s Infrastructure : what happens when a project’s public documentation persists after the team has moved on, leaving a valid, never-expired credential in a README that nobody is watching https://brandefense.io/blog/abandoned-digital-assets-ai-infrastructure/
Final Thoughts
The GitLab incoming email token attack path is not a zero-day exploit. There is no CVE. There is no patch. The feature works exactly as GitLab designed it. What makes it a meaningful risk is a combination of three properties that are individually unremarkable but collectively dangerous: the token is account-wide in scope, it never expires, and the standard developer guidance is to publish the address that contains it in public-facing documentation.
The remediation is straightforward: reset the token, audit recent commits, stop publishing the address. But performing that remediation requires first knowing the token is out there. That is the part most security programs miss.
Developer documentation is not the attack surface that perimeter security tools are designed to monitor. It is exactly the kind of exposure that continuous external visibility is built to find. A credential published in a README is still a credential. The fact that it was published on purpose does not make it any less exposed.
