CVE-2023-4812: GitLab CODEOWNERS Auth Bypass Vulnerability

CVE-2023-4812 Overview

An authorization bypass vulnerability has been discovered in GitLab Enterprise Edition (EE) that allows attackers to circumvent the required CODEOWNERS approval mechanism. This vulnerability affects GitLab EE versions starting from 15.3 before 16.5.6, all versions starting from 16.6 before 16.6.4, and all versions starting from 16.7 before 16.7.2. The flaw enables malicious actors to bypass the mandatory CODEOWNERS approval process by adding changes to a previously approved merge request.

Critical Impact

Attackers can bypass code review controls by modifying approved merge requests, potentially allowing unauthorized or malicious code to be merged into protected branches without required CODEOWNERS approval.

Affected Products

• GitLab Enterprise Edition versions 15.3 to 16.5.5
• GitLab Enterprise Edition versions 16.6 to 16.6.3
• GitLab Enterprise Edition versions 16.7.0 and 16.7.1

Discovery Timeline

• 2024-01-12 - CVE CVE-2023-4812 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-4812

Vulnerability Analysis

This vulnerability is classified as Improper Authorization (CWE-863), representing a significant weakness in GitLab's access control implementation for the CODEOWNERS feature. The CODEOWNERS functionality is designed to enforce mandatory code review from designated team members before code can be merged into protected branches. However, a logic flaw in the approval validation process allows this security control to be bypassed.

The vulnerability exists in how GitLab handles approval state persistence for merge requests. When a merge request receives the required CODEOWNERS approval, that approval state is not properly invalidated when subsequent changes are pushed to the merge request. This creates a race condition where an attacker can obtain initial approval for benign changes, then push malicious modifications while retaining the previously granted approval status.

Root Cause

The root cause lies in the improper validation of approval state when changes are added to an already-approved merge request. GitLab's merge request approval logic fails to re-evaluate the CODEOWNERS approval requirements when new commits are pushed to a previously approved merge request. The system should invalidate existing approvals and require re-approval from designated CODEOWNERS when the merge request content changes, but this validation step is bypassed under certain conditions.

Attack Vector

The attack can be executed remotely over the network without requiring authentication in certain configurations. An attacker with write access to a repository can exploit this vulnerability through the following attack flow:

1. The attacker creates a merge request with legitimate, non-malicious changes
2. The merge request receives the required CODEOWNERS approval
3. After approval is granted, the attacker pushes additional malicious commits to the same merge request
4. The approval state persists despite the new changes, bypassing the CODEOWNERS review requirement
5. The merge request can now be merged with malicious code that was never reviewed by the designated CODEOWNERS

This vulnerability is particularly concerning in environments where CODEOWNERS is used as a critical security control for sensitive code paths or configuration files. Technical details and the original security report can be found in the HackerOne Security Report and the GitLab Issue Report.

Detection Methods for CVE-2023-4812

Indicators of Compromise

• Merge requests that were merged with commits added after the final CODEOWNERS approval timestamp
• Audit logs showing merge request approvals followed by additional commits from different users
• Protected branches with merged code that lacks proper CODEOWNERS sign-off for all changes
• Unusual patterns of rapid approval-then-push activity on sensitive repositories

Detection Strategies

• Review GitLab audit logs for merge requests where commits were added after approval was granted
• Implement custom webhooks to monitor for post-approval commits on merge requests targeting protected branches
• Use GitLab's API to audit merge request history and compare approval timestamps against commit timestamps
• Configure alerts for merge requests that are merged within a short timeframe after receiving approval and new commits

Monitoring Recommendations

• Enable comprehensive audit logging for all merge request activities including approvals and commit pushes
• Monitor protected branch merge events and cross-reference with CODEOWNERS approval records
• Implement automated compliance checks to verify all merged code received proper CODEOWNERS approval
• Set up alerts for any merge request modifications occurring after approval has been granted

How to Mitigate CVE-2023-4812

Immediate Actions Required

• Upgrade GitLab Enterprise Edition to version 16.5.6, 16.6.4, or 16.7.2 or later depending on your current version branch
• Audit recent merge requests to identify any that may have been merged using this bypass technique
• Review code merged during the vulnerable period for any unauthorized or malicious changes
• Enable additional branch protection rules as a defense-in-depth measure

Patch Information

GitLab has released security patches addressing this vulnerability in the following versions:

• GitLab EE 16.5.6 for the 16.5.x branch
• GitLab EE 16.6.4 for the 16.6.x branch
• GitLab EE 16.7.2 for the 16.7.x branch

Organizations should upgrade to the latest patched version corresponding to their current deployment branch. The fix ensures that CODEOWNERS approval is properly invalidated when new commits are pushed to a merge request, requiring re-approval before merge.

Workarounds

• Implement a policy requiring manual verification of all commits in a merge request before final merge approval
• Use GitLab's merge request approval rules to require multiple approvers, reducing single point of failure
• Configure CI/CD pipelines to validate that the last commit timestamp predates the approval timestamp
• Temporarily restrict merge permissions to trusted administrators until patches can be applied

# Configuration example - Enable strict approval requirements
# In gitlab.rb, ensure these settings are configured:
gitlab_rails['approval_rules_require_all_approvals'] = true

# Verify GitLab version to ensure patched release
gitlab-rake gitlab:env:info | grep "GitLab information"

# Check current GitLab EE version
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION