CVE-2026-9807: GitLab Project Access Token Authorization Bypass Vulnerability

Technical summary

CVE-2026-9807 addresses an authorization enforcement bypass in GitLab CE/EE caused by improper access control logic in Project Access Token validation. The flaw stems from CWE-863 (Incorrect Authorization) and manifests when a Project Access Token transitions to a blocked or revoked state—the system fails to fully deny subsequent API or resource access requests using that token. Affected versions include 18.9 through 18.10.6, 18.11 through 18.11.3, and 19.0 through 19.0.0. The vulnerability requires network access and valid GitLab credentials but does not require special user interaction; however, the attacker must either control the blocked token or influence its creation.

Business impact

Organizations using affected GitLab versions face confidentiality risk if former or terminated token holders, or accounts that intentionally revoke access, retain the ability to view private project data through unrevoked token channels. While the CVSS score of 4.3 reflects limited scope, the business impact depends on token proliferation practices and data sensitivity. Teams relying on token-based access revocation for offboarding or privilege reduction workflows should treat this as a control failure—blocked tokens may not have actually blocked access during the vulnerable window. This could affect compliance posture if audit logs show tokens as revoked when they continued functioning.

Affected systems

GitLab Community Edition (CE) and Enterprise Edition (EE) versions 18.9–18.10.6, 18.11–18.11.3, and 19.0–19.0.0 are vulnerable. Self-hosted and SaaS GitLab instances running these versions should be inventoried and prioritized for upgrade. Later versions in each release line (18.10.7 and above, 18.11.4 and above, 19.0.1 and above) contain the fix. Patch versions vary by release channel; verify against GitLab's security advisory for your specific deployment.

Exploitability

Exploitation requires prior GitLab authentication and knowledge of or ability to create/control a Project Access Token. The attacker then attempts to access private resources after the token is supposed to be blocked. Because the vulnerability only manifests after a token is blocked, exploitation is more likely in scenarios where an attacker maintains control over a token that an administrator subsequently tries to revoke, or where a compromised service account's token is not fully disabled. The network-accessible nature (CVSS AV:N) and low privilege requirements (PR:L) lower the barrier, but the condition that a token must be blocked first somewhat constrains real-world attack surface. No public exploit code is known; the vulnerability is likely being patched proactively by most operators.

Remediation

Upgrade GitLab instances to patched versions immediately: 18.10.7 or later, 18.11.4 or later, or 19.0.1 or later, depending on your current minor version. After patching, conduct an audit of active Project Access Tokens, especially any created or managed during the window when your instance ran vulnerable code. Consider rotating tokens that existed across the vulnerability window and reviewing access logs for unexpected API calls using blocked tokens. If you cannot patch immediately, implement network-level restrictions on GitLab API endpoints and review token-based access policies in your change management process.

Patch guidance

GitLab has released fixes across three release tracks. Identify your current version (Settings > About GitLab in the web interface) and cross-reference the affected ranges above. For versions 18.9.x through 18.10.6, upgrade to 18.10.7 or later. For 18.11.x through 18.11.3, upgrade to 18.11.4 or later. For 19.0.0, upgrade to 19.0.1 or later. Test patches in a non-production environment first, particularly if you rely on token-based CI/CD pipelines—confirm that intentionally blocked tokens are properly denied after patching. Review GitLab's official advisory for any database migrations or additional post-patch steps.

Detection guidance

Monitor GitLab API access logs and audit trails for API calls using Project Access Tokens that were marked as revoked or blocked in the token management interface. Compare token creation/revocation timestamps against subsequent API activity; activity after revocation during the vulnerable window warrants investigation. Review access logs for private projects to identify unusual or unexpected API token usage. Enable or increase logging verbosity for API authentication and token validation if available. In Kubernetes-based deployments, check audit logs for token-based service account access to private repositories that should have been denied.

Why prioritize this

This vulnerability scores MEDIUM (4.3) but should not be deprioritized purely on CVSS. The combination of network accessibility, low privilege requirements, and the nature of access tokens—which are often scattered across CI/CD pipelines, automation tools, and third-party integrations—makes comprehensive risk assessment necessary. If your organization uses GitLab Project Access Tokens for automated pipelines or integrations and has an offboarding or deprovisioning workflow that relies on token revocation, prioritize patching. If you rarely use Project Access Tokens or maintain strict segregation of token lifecycle management, the risk is lower but should still be addressed within a reasonable timeframe (30–60 days).

Risk score, explained

The CVSS 3.1 score of 4.3 (MEDIUM) reflects: Network-accessible attack surface (AV:N), low attack complexity (AC:L), low privilege requirement (PR:L), no user interaction (UI:N), single scope boundary (S:U), limited confidentiality impact (C:L), no integrity or availability impact (I:N/A:N). The score appropriately weights the need for prior authentication and the bounded impact to confidentiality. However, the *business* risk may exceed the score if token-based access control is central to your architecture, if affected tokens have long lifespans, or if revocation is a critical compliance control.

Frequently asked questions