CVE-2026-9807: GitLab Auth Bypass Vulnerability

CVE-2026-9807 Overview

GitLab has patched an authorization enforcement flaw in GitLab Community Edition (CE) and Enterprise Edition (EE). The issue allowed a blocked Project Access Token to continue accessing private resources under certain conditions. The flaw affects GitLab CE/EE versions 18.9 before 18.10.7, 18.11 before 18.11.4, and 19.0 before 19.0.1. The weakness is classified under [CWE-863]: Incorrect Authorization. An authenticated attacker holding a token that an administrator had explicitly blocked could continue to read private project data through network-accessible interfaces.

Critical Impact
A blocked Project Access Token could bypass revocation controls and retain read access to private GitLab project resources, undermining token lifecycle and incident response workflows.

Affected Products

GitLab CE/EE 18.9 through versions before 18.10.7
GitLab CE/EE 18.11 before 18.11.4
GitLab CE/EE 19.0 before 19.0.1

Discovery Timeline

2026-05-27 - GitLab releases patch release 19.0.1 addressing the issue
2026-05-28 - CVE-2026-9807 published to NVD
2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-9807

Vulnerability Analysis

The vulnerability stems from incorrect authorization enforcement on Project Access Tokens within GitLab CE/EE. Project Access Tokens are scoped credentials used by automation, CI/CD pipelines, and integrations to interact with GitLab APIs. When an administrator blocks a token, GitLab is expected to reject any subsequent authenticated request bearing that token. Under specific conditions in affected versions, the authorization layer failed to honor the blocked state. The token continued to authenticate API calls and return private project data. The flaw is a logic gap in the access control pathway rather than a memory safety or injection issue.

Root Cause

The root cause is improper authorization checking [CWE-863] in the code path that validates Project Access Token state. The blocked status was not consistently consulted before granting access to private resources. Revocation, a core control for token lifecycle management, was therefore not enforced in all execution paths.

Attack Vector

Exploitation requires network access to a vulnerable GitLab instance and possession of a Project Access Token that has been blocked. No user interaction is required. The attacker submits standard API requests using the blocked token. The server returns private resource content instead of rejecting the request. Confidentiality of project data is the primary impact. Integrity and availability are not affected.

No public proof-of-concept code is available. See the GitLab Patch Release Note, GitLab Work Item Detail, and HackerOne Security Report for vendor and researcher details.

Detection Methods for CVE-2026-9807

Indicators of Compromise

API access log entries showing successful authentication from a Project Access Token after its blocked timestamp
Repository read events, clone operations, or API queries against private projects originating from tokens marked as revoked or blocked in the GitLab admin panel
Unexpected token activity in audit_events for tokens that should have been disabled

Detection Strategies

Correlate GitLab audit_events and application.log entries with the Project Access Tokens administrative interface to identify tokens used after being blocked
Query GitLab API endpoints /api/v4/projects/:id/access_tokens for token state and compare against authentication events
Alert on any 200-status API response associated with a token ID that appears in the blocked tokens registry

Monitoring Recommendations

Forward GitLab audit and application logs to a centralized analytics platform and create rules for blocked-token usage patterns
Periodically reconcile active token inventories with expected token state in CI/CD systems
Track anomalous spikes in private project read activity per token to surface unintended access

How to Mitigate CVE-2026-9807

Immediate Actions Required

Upgrade GitLab CE/EE to 18.10.7, 18.11.4, or 19.0.1 or later as appropriate for your release branch
Audit all Project Access Tokens currently marked as blocked and review their recent API activity
Rotate or revoke and recreate any Project Access Tokens that may have been used while in a blocked state

Patch Information

GitLab released patch versions 18.10.7, 18.11.4, and 19.0.1 on 2026-05-27 to correct the authorization enforcement logic. Self-managed administrators should apply the upgrade following the official GitLab Patch Release Note. GitLab.com SaaS instances are patched by the vendor.

Workarounds

Delete rather than block Project Access Tokens that must be revoked until the patch is applied
Restrict token scopes and project membership to the minimum required, reducing the impact of any token that resists revocation
Limit network exposure of self-managed GitLab instances to trusted networks where feasible

bash

# Verify installed GitLab version and upgrade to a fixed release
sudo gitlab-rake gitlab:env:info | grep -i version

# Debian/Ubuntu example: upgrade to a patched release
sudo apt-get update && sudo apt-get install gitlab-ee=19.0.1-ee.0

# RHEL/CentOS example
sudo yum install gitlab-ee-19.0.1-ee.0

# Delete (rather than block) a Project Access Token via API as an interim control
curl --request DELETE \
  --header "PRIVATE-TOKEN: <admin_token>" \
  "https://gitlab.example.com/api/v4/projects/<project_id>/access_tokens/<token_id>"