CVE-2026-1322: GitLab CE/EE Authorization Bypass Vulnerability

CVE-2026-1322 Overview

CVE-2026-1322 is an improper authorization vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). The flaw allows an authenticated user holding an OAuth application token with the read_api scope to create issues and add comments within private projects. The read_api scope is intended to permit only read operations, so this behavior violates the documented authorization model. The issue affects all GitLab versions from 16.0 before 18.9.7, 18.10 before 18.10.6, and 18.11 before 18.11.3. GitLab patched the issue in the 13 May 2026 patch release.

Critical Impact
An attacker with a read_api OAuth token can write to private project issue trackers, undermining repository integrity and confidentiality boundaries.

Affected Products

GitLab CE/EE versions 16.0 through 18.9.6
GitLab CE/EE versions 18.10 through 18.10.5
GitLab CE/EE versions 18.11 through 18.11.2

Discovery Timeline

2026-05-13 - GitLab releases patch versions 18.9.7, 18.10.6, and 18.11.3
2026-05-14 - CVE-2026-1322 published to NVD
2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-1322

Vulnerability Analysis

The vulnerability is an authorization flaw classified under [CWE-840] (Business Logic Errors). GitLab OAuth applications can request scoped tokens that restrict their permissions. The read_api scope advertises read-only access to the GitLab API surface. Due to incorrect authorization checks on issue and comment creation endpoints, requests authenticated with a read_api token are accepted for write operations against private projects. An attacker who controls or compromises such a token can inject issues and comments into projects the underlying user can access, including private repositories.

The attack requires network access to the GitLab instance, valid authentication, and a high-complexity exploitation path due to token possession requirements. The vulnerability affects both confidentiality and integrity of private project data while leaving availability intact.

Root Cause

The root cause is an enforcement gap between the declared OAuth scope and the controller-level authorization logic for issue creation and comment endpoints. The endpoints did not validate that the presenting token carried a write-capable scope such as api before permitting state-changing operations.

Attack Vector

Exploitation requires an authenticated user and an OAuth application token issued with the read_api scope. The attacker submits API requests to issue creation or note creation endpoints under a private project the token's user can reach. Because the scope check is improper, the requests are honored. No user interaction is required. Refer to the GitLab Work Item Overview and the HackerOne Security Report #3508895 for additional technical context.

No verified public exploit code is available. The vulnerability mechanism is described in prose because no validated proof-of-concept has been published.

Detection Methods for CVE-2026-1322

Indicators of Compromise

Unexpected issue or note creation events in private projects authored through OAuth tokens whose registered scope is read_api.
API audit log entries showing POST /api/v4/projects/:id/issues or POST /api/v4/projects/:id/issues/:iid/notes from tokens not previously associated with write activity.
New issues or comments attributed to OAuth applications that, per their configuration, should only perform read operations.

Detection Strategies

Correlate the scopes field of access tokens with the HTTP method and endpoint accessed in GitLab audit and production JSON logs.
Baseline OAuth application behavior and alert on first-seen write operations from read_api only applications.
Review the oauth_access_tokens table for tokens with read_api scope that have generated write events.

Monitoring Recommendations

Enable and forward GitLab audit events and API logs to a centralized analytics platform for retrospective hunting.
Track issue and note creation rates per OAuth application and alert on anomalies in private projects.
Periodically reconcile installed OAuth applications, their declared scopes, and the operations observed in production.

How to Mitigate CVE-2026-1322

Immediate Actions Required

Upgrade self-managed GitLab instances to 18.9.7, 18.10.6, or 18.11.3 as appropriate for your release stream.
Inventory all OAuth applications and revoke tokens that are no longer required or whose scopes are broader than necessary.
Audit private project issue and comment history covering the affected version window for unexpected entries.

Patch Information

GitLab addressed the issue in the 13 May 2026 patch release. Fixed versions are GitLab CE/EE 18.9.7, 18.10.6, and 18.11.3. Details are published in the GitLab Patch Release Announcement. GitLab.com hosted instances have already been updated by the vendor.

Workarounds

Rotate or revoke OAuth tokens carrying the read_api scope until the upgrade is applied.
Restrict creation of new OAuth applications and tighten administrative review of requested scopes.
Limit network exposure of the GitLab API to trusted ranges where operationally feasible.

bash

# Revoke a suspicious OAuth access token via the GitLab API
curl --request POST \
  --header "PRIVATE-TOKEN: <admin_personal_access_token>" \
  "https://gitlab.example.com/api/v4/oauth/revoke" \
  --data "token=<suspect_oauth_token>"