Incorrect Authorization in GitLab
Description
An issue has been discovered in GitLab EE affecting all versions starting from 15.3 before 16.5.6, all versions starting from 16.6 before 16.6.4, all versions starting from 16.7 before 16.7.2. The required CODEOWNERS approval could be bypassed by adding changes to a previously approved merge request.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE allowed bypassing CODEOWNERS approval by merging additional changes into an approved merge request, affecting versions before 16.5.6, 16.6.4, and 16.7.2.
Vulnerability
The vulnerability exists in the CODEOWNERS approval enforcement logic in GitLab EE. When a merge request is approved, subsequent changes added to the source branch via another merge request that is merged into that branch do not trigger re-approval, even if the project settings require approval reset on new commits. Affected versions: all versions starting from 15.3 before 16.5.6, all versions starting from 16.6 before 16.6.4, all versions starting from 16.7 before 16.7.2. [1]
Exploitation
An attacker with developer access can create a merge request to a protected branch with CODEOWNERS approval required. After the owner approves, the attacker creates a second merge request targeting the first MR's source branch, adds malicious changes, and merges it. The first MR remains approved, allowing the attacker to merge it with unauthorized code. [1]
Impact
The attacker can bypass mandatory CODEOWNERS review, pushing arbitrary changes to protected files without proper approval, undermining the integrity of the codebase. This could lead to unauthorized code modifications, potentially introducing vulnerabilities or backdoors.
Mitigation
GitLab has released fixed versions: 16.5.6, 16.6.4, and 16.7.2. All users should upgrade to these or later versions. No workaround is available. The issue is not listed in CISA's Known Exploited Vulnerabilities catalog. [1]
AI Insight generated on May 23, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: 15.3 before 16.5.6, 16.6 before 16.6.4, 16.7 before 16.7.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Merge request approval state is not invalidated when new commits are introduced into the source branch via a secondary merge request merged into it."
Attack vector
An attacker creates a merge request from branch `test` to `main` containing a file owned by a CODEOWNER. After the CODEOWNER approves, the attacker creates a second merge request from branch `test2` to `test`, modifies the same file with malicious content, and merges it. The first merge request remains approved despite new code being added, allowing the attacker to merge without the CODEOWNER's re-approval [ref_id=1]. The attack requires the attacker to have developer-level access to create branches and merge requests, and the project must have CODEOWNERS approval enforcement enabled.
Affected code
The vulnerability exists in GitLab's merge request approval logic for CODEOWNERS rules. The issue is in how the system determines whether a previously approved merge request should have its approvals reset when new commits are added via a secondary merge request merged into the source branch. The advisory does not specify exact file paths or function names.
What the fix does
The advisory does not include a published patch diff. Based on the issue description, the fix should ensure that when new commits are introduced into a merge request's source branch (via merging another branch into it), the CODEOWNERS approval is invalidated and must be re-obtained. GitLab addressed this in versions 16.5.6, 16.6.4, and 16.7.2 by correcting the logic that determines when approval should be reset upon new changes.
Preconditions
- configProject must have CODEOWNERS approval enforcement enabled on protected branches
- authAttacker must have developer-level access to create branches and merge requests
- inputA CODEOWNER must have approved the initial merge request
Reproduction
1. Create a group and project with CODEOWNERS file setting `README.md @userA`. Enable CODEOWNERS approval on the protected `main` branch. Configure merge request settings to reset approvals when new code is added. 2. As a non-owner user, edit README.md and create a merge request from branch `test` to `main`. 3. Have userA (the CODEOWNER) approve the merge request. 4. From the non-owner account, edit README.md again on branch `test2` with `test` as the base, and create a merge request from `test2` to `test`. 5. Merge `test2` into `test`. 6. Observe that the original merge request (test→main) remains approved and can be merged without re-approval [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- hackerone.com/reports/2115574mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/424398mitreissue-trackingpermissions-required
News mentions
1- GitLab Critical Security Release: 16.7.2, 16.6.4, 16.5.6GitLab Security Releases · Jan 11, 2024