CVE-2023-2013
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 1.2 before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2. An issue was found that allows someone to abuse a discrepancy between the Web application display and the git command line interface to social engineer victims into cloning non-trusted code.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE allows social engineering via ambiguous branch names that display differently in web UI vs git CLI, tricking users into cloning malicious code.
Vulnerability
GitLab CE/EE versions starting from 1.2 before 15.10.8, all versions from 15.11 before 15.11.7, and all versions from 16.0 before 16.0.2 contain a discrepancy between the web interface display and the git command line interface when handling branch names. Specifically, branch names such as heads/main can be interpreted differently by Git's ref resolution rules, allowing an attacker to create a branch that appears as one thing in the web UI but resolves to a different branch when cloned via git clone or git fetch. This is due to Git's symbolic ref name disambiguation, where heads/foo may resolve to either refs/heads/foo or refs/heads/heads/foo [1].
Exploitation
An attacker with push access to a repository can create a branch with a name like heads/main. In the GitLab web interface, this branch may be displayed as heads/main, but when a victim uses git clone or git fetch with a reference to that branch, Git's ref resolution may interpret it as refs/heads/heads/main or refs/heads/main depending on ambiguity. The attacker can craft the branch to contain malicious code. The victim, seeing a legitimate-looking branch name in the web UI, may be social engineered into cloning or checking out that branch, thereby executing untrusted code [1].
Impact
Successful exploitation allows an attacker to trick a victim into cloning or checking out a branch containing malicious code. This could lead to arbitrary code execution on the victim's machine, depending on the nature of the malicious code. The attacker does not need to compromise the victim's account; only the ability to push branches to a repository that the victim has access to is required. The impact includes potential information disclosure, code execution, or further compromise of the victim's environment [1].
Mitigation
The issue is fixed in GitLab CE/EE versions 15.10.8, 15.11.7, and 16.0.2. Users should upgrade to these versions or later. No workaround is mentioned in the available reference. The vulnerability is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog as of the publication date [1].
AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=1.2, <15.10.8 || >=15.11, <15.11.7 || >=16.0, <16.0.2
- Range: >=1.2, <15.10.8
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"GitLab's web interface resolves the ambiguous branch name `heads/main` differently than the Git command-line client, displaying the wrong branch content to the user."
Attack vector
An attacker creates a repository with a branch named `heads/main` as the default branch, containing malicious code. They then create a separate `main` branch with benign-looking content. When a victim views the repository on GitLab's web interface, the UI displays the content of the `main` branch (the safe-looking code), but when the victim clones the repository, Git's command-line interface resolves the default branch reference `heads/main` to `refs/heads/heads/main` (the malicious branch). This discrepancy between the web display and the actual cloned content social engineers the victim into executing malicious code they believe is safe [ref_id=1].
Affected code
The vulnerability involves GitLab's handling of ambiguous branch names, specifically a branch named `heads/main`. The issue is in the Web application's display logic, which shows the content of the `main` branch (the genuine branch) while the repository's default branch is actually `heads/main` (the malicious branch). No specific function or file path is named in the advisory [ref_id=1].
What the fix does
The advisory does not include a patch diff. The issue was reported via HackerOne and assigned to GitLab developers for fixing. Based on the report, the remediation would need to ensure that GitLab's web interface correctly resolves and displays the content of the actual default branch (e.g., `heads/main`) rather than showing a differently-named branch like `main` when ambiguity exists. No fix is published in the provided bundle [ref_id=1].
Preconditions
- authAttacker must be able to create a repository and push branches with names like `heads/main`
- inputVictim must view the repository on GitLab's web interface and then clone it via Git CLI
- configThe repository must have both a `heads/main` branch (as default) and a `main` branch with different content
Reproduction
1. Create an empty repository on GitLab (without a README). 2. Clone the repo, create a branch named `heads/main`, add malicious content (e.g., a `script.sh`), commit, and push it as `refs/heads/heads/main`. This becomes the default branch. 3. Create a separate `main` branch with benign content (e.g., a safe `script.sh`) and push it as `refs/heads/main`. 4. As a victim, visit the repository page on GitLab — the web UI shows the content of the `main` branch (safe). 5. Clone the repository and execute `script.sh` — the malicious code from the `heads/main` branch runs instead [ref_id=1].
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
1- GitLab Security Release: 16.0.2, 15.11.7, and 15.10.8GitLab Security Releases · Jun 5, 2023