Incorrect Authorization in GitLab
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.7 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1. This allowed a developer to remove the CODEOWNERS rules and merge to a protected branch.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE allowed developers to bypass CODEOWNERS branch protection by creating a tag with the same name as a protected branch, enabling unauthorized merges.
Vulnerability
In GitLab CE/EE versions 13.7 through 15.11.10, 16.0 through 16.0.6, and 16.1 through 16.1.1, a bug in the handling of Git ref names allowed a user with Developer role to bypass CODEOWNERS branch protection rules. The issue occurs because Git’s ref resolution algorithm prioritizes tags over branches when a tag has the same name as a protected branch, causing the CODEOWNERS file associated with the tag to be used instead of the branch’s file, effectively removing the required approval rules [1].
Exploitation
An attacker with Developer role on a repository can create a tag with the same name as a protected branch that has CODEOWNERS rules. When submitting a merge request targeting that branch, GitLab resolves the ambiguous ref name by using the tag’s CODEOWNERS file, which may not contain the required approvals. This allows the merge to proceed without the necessary reviews [1].
Impact
Successful exploitation enables a Developer to merge code into a protected branch without the required CODEOWNERS approval, bypassing the intended branch protection policy. This could lead to unauthorized code changes being introduced into critical branches [1].
Mitigation
GitLab has addressed this vulnerability in versions 15.11.10, 16.0.6, and 16.1.1. Users should upgrade to one of these fixed versions or later. No workaround is available beyond restricting Developer permissions [1].
AI Insight generated on May 26, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=13.7 <15.11.10, >=16.0 <16.0.6, >=16.1 <16.1.1
- Range: 13.7
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"GitLab resolves CODEOWNERS rules using Git's ambiguous ref name resolution, which matches tags before branches, allowing a tag with the same name as a protected branch to override the branch's CODEOWNERS file."
Attack vector
An attacker with Developer role on a repository creates a tag with the same name as a protected branch (e.g., `devel`) that has Code Owner approval enabled. Because Git resolves ambiguous ref names by checking tags before branches, GitLab reads the CODEOWNERS file from the tag instead of the branch. The attacker first pushes a tag that either removes or omits the CODEOWNERS file, then creates a merge request from a feature branch to the protected branch. Since the tag's CODEOWNERS (or lack thereof) is evaluated, the Code Owner approval requirement is bypassed, allowing the attacker to merge without approval [ref_id=1].
Affected code
The vulnerability lies in GitLab's handling of ambiguous Git ref names when resolving CODEOWNERS rules. When a tag and a branch share the same name, Git's ref resolution rules (as documented in gitrevisions) cause `refs/tags/<refname>` to be matched before `refs/heads/<refname>`. GitLab's CODEOWNERS evaluation follows this same resolution order, so a tag's CODEOWNERS file (or lack thereof) takes precedence over the branch's CODEOWNERS file [ref_id=1].
What the fix does
The issue was addressed in GitLab versions 15.11.10, 16.0.6, and 16.1.1. While the advisory does not include a specific patch diff, the fix ensures that GitLab resolves CODEOWNERS rules against the branch ref (`refs/heads/<refname>`) rather than following Git's ambiguous ref resolution order. This prevents a tag with the same name as a protected branch from overriding the branch's CODEOWNERS approval requirements [ref_id=1].
Preconditions
- authAttacker must have Developer role on the target repository
- configThe target protected branch must not be the default branch (since tags matching the default branch cannot be created)
- configThe protected branch must have Code Owner approval enabled
- inputAttacker must be able to push tags to the repository
Reproduction
1. (Victim) Create a private repository, add a CODEOWNERS file (`* @root`), create a non-default branch `devel`, protect `devel` with Code Owner approval enabled, and add the attacker as a Developer member. 2. (Attacker) Clone the repo, checkout the `devel` branch, delete the CODEOWNERS file, commit, and push as a tag: `git push origin devel_tag:refs/tags/devel`. 3. (Attacker) Create a feature branch `hack` from `origin/devel`, add a malicious file, push it, and create a merge request from `hack` to `devel`. 4. (Attacker) Merge the merge request — it succeeds without Code Owner approval. Optionally delete the tag to cover tracks: `git push origin -d refs/tags/devel` [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- hackerone.com/reports/1898054mitretechnical-descriptionexploit
- gitlab.com/gitlab-org/gitlab/-/issues/410123mitreissue-tracking
News mentions
1- GitLab Security Release: 16.1.1, 16.0.6, and 15.11.10GitLab Security Releases · Jun 29, 2023