CVE-2024-0410 is a high severity (CVSS 7.7) authorization bypass in GitLab. A developer could bypass CODEOWNERS approvals by creating a merge conflict. It affects 15.1 before 16.7.6, 16.8 before 16.8.3 and 16.9 before 16.9.1. Upgrade to a fixed release.
What's affected
Per the record, GitLab versions 15.1 before 16.7.6, 16.8 before 16.8.3, and 16.9 before 16.9.1. The fixed builds are therefore 16.7.6, 16.8.3 and 16.9.1, or any later release.
The weakness is CWE-841, improper enforcement of behavioral workflow. The code owners feature exists so that certain files need sign off from named people before a merge request lands. The flaw lets a developer get around that sign off.
The vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N: network, high complexity, low privileges and user interaction, with a scope change and high confidentiality and integrity impact. The public GitLab issue we read describes a report that code owner approvals could be bypassed, and uses a project that resets code owner approvals when protected files change. It gives no separate severity score, and the HackerOne report page linked by the record would not load for us. We did not find a conflicting severity. It is not on the CISA Known Exploited Vulnerabilities list.
How to check if you're exposed
Check the GitLab version on your self-managed instance. Signed in, the version appears on the help page. On the server:
sudo gitlab-rake gitlab:env:info
Then check whether you rely on code owners. Look for a CODEOWNERS file in your repositories, and for protected branch settings that require approval from code owners. If you do not use code owners, the flaw has little to bypass, although the upgrade is still sensible.
For a review of past activity, look at merged merge requests that touched files covered by a CODEOWNERS rule and check that the approvers match what you expect. Pay attention to merge requests that had conflicts resolved before the merge.
What to do now
- Find your GitLab version on every self-managed instance.
- Upgrade to 16.7.6, 16.8.3, 16.9.1 or later.
- Audit recent merges to protected paths, such as CI configuration, deployment files and security sensitive code, against the expected approvers.
- Keep a second control on the most sensitive files, for example a required status check or a branch protection rule that does not depend only on code owner approval.
- Limit who holds the developer role on projects that guard sensitive files.
Why it matters
Code owner rules are a review control. When they can be skipped, the control gives false comfort, because the merge history looks reviewed when it was not. The files most often covered by code owners are pipeline definitions and deployment settings, which are exactly where unreviewed changes do the most harm.
The weakness class is about a step in a workflow that is supposed to be enforced and is not, in one particular path. Here that path is a merge conflict. The fix restores the check. For anyone running a pipeline gate, the lesson is to test negative cases, such as what happens when a merge request conflicts.
Quick check
Who can exploit CVE-2024-0410?
The record says a developer. It needs a valid account with enough rights to open merge requests in the project.
Which versions fix CVE-2024-0410?
16.7.6, 16.8.3 and 16.9.1 for their lines, per the record. Later releases also include the fix.
Sources
Last reviewed: 19 October 2026.
