Missing Authorization in GitLab
Description
An issue has been discovered in GitLab EE affecting all versions from 16.4 prior to 16.6.7, 16.7 prior to 16.7.5, and 16.8 prior to 16.8.2 which allows a maintainer to change the name of a protected branch that bypasses the security policy added to block MR.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE allows maintainers to bypass block_branch_modification policy by renaming a protected branch before merging MRs.
Vulnerability
An issue in GitLab EE affecting all versions from 16.4 prior to 16.6.7, 16.7 prior to 16.7.5, and 16.8 prior to 16.8.2 allows a maintainer to rename a protected branch, thereby bypassing the group's scan result policy block_branch_modification setting [1]. This setting is intended to prevent users from removing branches from the protected list, deleting protected branches, or changing the default branch when covered by a security policy [1].
Exploitation
A maintainer with write access to a project can rename a protected branch (e.g., via the project settings or API). By changing the branch name, the branch no longer matches the protection rules defined by the security policy, thus evading the block_branch_modification restriction [1]. The attacker does not need special privileges beyond maintainer and can perform the rename without triggering policy enforcement [1].
Impact
Successful exploitation allows a maintainer to remove protection from a branch, delete it, or change the default branch, defeating the intended security control [1]. This could enable merging vulnerable code without the required approvals, leading to unauthorized code changes and potential compromise of the branch's integrity [1].
Mitigation
GitLab has released fixed versions: 16.6.7, 16.7.5, and 16.8.2, which address the issue [1]. Users should upgrade to these or later versions. No workaround is available in affected versions [1].
AI Insight generated on May 24, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >= 16.4, < 16.6.7, >= 16.7, < 16.7.5, >= 16.8, < 16.8.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization check in `ProtectedBranches::UpdateService` allows a maintainer to rename a protected branch, bypassing the `block_branch_modification` security policy setting."
Attack vector
A project maintainer can bypass a group's scan result policy that has `block_branch_modification` enabled by sending a PATCH request to update the protected branch's name. The attacker first retrieves the protected branch ID via a GET request to `/api/v4/projects/PROJECT_ID/protected_branches`, then sends a PATCH request with a new `name` value (e.g., `"messed_up"`) and `allow_force_push: true`. This effectively removes the protection from the original branch, allowing the maintainer to push vulnerable code to what was previously a protected branch [ref_id=1].
Affected code
The vulnerability lies in the `ProtectedBranches::UpdateService` in the EE codebase. The service does not prevent a maintainer from changing the `name` field of a protected branch via the REST API or GraphQL mutation. The fix introduces a new module `EE::ProtectedBranches::RenamingBlockedByPolicy` that checks whether a rename is attempted while a scan result policy with `block_branch_modification` is active [ref_id=1].
What the fix does
The fix introduces the `RenamingBlockedByPolicy` module that is prepended into `EE::ProtectedBranches::UpdateService`. When the update params include a `:name` key (indicating a rename), the service checks whether a scan result policy with `block_branch_modification` is active for the project or group. If so, it raises `Gitlab::Access::AccessDeniedError`, blocking the rename. A new scope `blocking_branch_modification` is added to `ScanResultPolicyRead` to efficiently query for policies with the setting enabled [ref_id=1].
Preconditions
- authThe attacker must have the Maintainer role on the project (not necessarily the group)
- configA group-level scan result policy with `block_branch_modification: true` must be active on the project
- networkThe attacker must have network access to the GitLab instance's API
- inputThe attacker must know the project ID and the protected branch ID
Reproduction
1. As a group owner, create a scan result policy with `block_branch_modification: true` using the YAML provided in the report [ref_id=1]. 2. Create a project in that group and invite a maintainer to the project. 3. As the maintainer, send `GET /api/v4/projects/PROJECT_ID/protected_branches` to get the protected branch ID. 4. Send a PATCH request to `/GROUP/PROJECT/-/protected_branches/ID` with body `{"protected_branch":{"name":"messed_up","allow_force_push":true}}`. 5. Verify the original branch is no longer protected and push code to it [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/2280292mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/435500mitreissue-trackingpermissions-required
News mentions
1- GitLab Security Release: 16.8.2, 16.7.5, 16.6.7GitLab Security Releases · Feb 7, 2024