CVE-2026-7487: GitLab EE Authorization Bypass Vulnerability

CVE-2026-7487 Overview

CVE-2026-7487 is an improper authorization vulnerability in GitLab Enterprise Edition (EE). The flaw allows an authenticated user holding the Reporter role to reset merge request approval rules on merge requests they authored. GitLab has patched the issue across three affected release branches.

The vulnerability stems from missing authorization checks on merge request approval rule modifications. Successful abuse weakens the code review integrity controls that protect protected branches and enforce policy-driven approvals. The weakness maps to CWE-1280: Improper Neutralization of Special Elements in Access Controls.

Critical Impact
A Reporter-role user who authored a merge request can bypass approval policy by resetting approval rules, undermining code review governance in affected GitLab EE instances.

Affected Products

GitLab Enterprise Edition versions 13.1 through 19.1.6
GitLab Enterprise Edition 19.2 versions before 19.2.5
GitLab Enterprise Edition 19.3 versions before 19.3.1

Discovery Timeline

2026-08-26 - CVE-2026-7487 published to NVD
2026-08-26 - Last updated in NVD database
Vendor advisory published as GitLab Patch Release 19.3.1
Report tracked in HackerOne Report #3669140 and GitLab Work Item #598657

Technical Details for CVE-2026-7487

Vulnerability Analysis

GitLab EE uses merge request approval rules to enforce policy such as required approver counts, code owner reviews, and protected branch controls. These rules are a governance mechanism to prevent authors from merging their own unreviewed code. The endpoint that manages approval rule state did not consistently verify that the requesting user held sufficient privileges to modify the rules on a merge request.

When a Reporter-role user authored a merge request, the authorization layer treated authorship as a partial privilege. Under specific conditions, this allowed the author to invoke the reset operation on approval rules attached to their own merge request. The reset removes or clears the approval configuration that would otherwise block merge without required reviewers.

The issue is a broken access control flaw rather than a code execution or memory safety bug. Exploitation requires an authenticated session, user interaction, and network access to the GitLab web interface or API.

Root Cause

The root cause is an authorization check that conflated resource authorship with the permission to modify merge request approval rules. Reporter is a low-privilege role intended for read and comment operations, not for altering approval policy. The missing role-based enforcement on the reset action created the privilege discrepancy.

Attack Vector

An authenticated attacker with Reporter access to a project creates a merge request they author. The attacker then triggers the approval rule reset action against their own merge request through the GitLab UI or API. Once approval rules are reset, downstream reviewers or automation may merge the request without the originally required approvals. Exploitation is limited to projects where the attacker already holds Reporter membership and can open merge requests.

No verified public exploit code is available. See the GitLab Work Item #598657 for vendor technical details.

Detection Methods for CVE-2026-7487

Indicators of Compromise

Audit log entries showing approval_rule.reset or equivalent approval rule modification events performed by users with Reporter role.
Merge requests that were merged with fewer approvals than the project policy requires on protected branches.
API calls to merge request approval rule endpoints originating from tokens tied to Reporter accounts.

Detection Strategies

Query GitLab audit events for approval rule changes correlated with the actor's project membership role at the time of the action.
Compare current approval rule state against baseline policy templates and alert on drift for merge requests authored by low-privilege users.
Review merge history on protected branches for merges lacking required reviewer counts documented in project policy.

Monitoring Recommendations

Forward GitLab audit events and API access logs to a centralized SIEM for role-versus-action correlation.
Alert on any approval rule reset performed by the merge request author when the author is not a Maintainer or Owner.
Track version and patch status of self-managed GitLab EE instances to confirm remediation coverage.

How to Mitigate CVE-2026-7487

Immediate Actions Required

Upgrade self-managed GitLab EE to version 19.3.1, 19.2.5, or 19.1.7 depending on the deployed branch.
Review recent merge activity on protected branches for merges completed without required approvals since the vulnerable window began.
Audit project memberships and remove Reporter access for accounts that do not require it.

Patch Information

GitLab addressed the issue in GitLab EE 19.1.7, 19.2.5, and 19.3.1. GitLab.com is operated on the patched release. Full remediation guidance is documented in the GitLab Patch Release 19.3.1 advisory.

Workarounds

Restrict merge request creation on sensitive projects to users with roles above Reporter until the upgrade is applied.
Enforce protected branch settings that require approvals from users other than the merge request author.
Configure merge request approval policies at the group level so project-level resets do not weaken enforcement.

bash

# Verify installed GitLab version on self-managed instances
sudo gitlab-rake gitlab:env:info | grep "GitLab information" -A 5

# Upgrade example for Omnibus GitLab on Debian/Ubuntu to a patched release
sudo apt-get update
sudo apt-get install gitlab-ee=19.3.1-ee.0
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart