CVE-2023-2001
Description
An issue has been discovered in GitLab CE/EE affecting all versions 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 attacker was able to spoof protected tags, which could potentially lead a victim to download malicious code.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab CE/EE allows attackers to spoof protected tags via branch names, potentially tricking victims into downloading malicious code.
Vulnerability
An issue in GitLab CE/EE allows an attacker to spoof protected tags, potentially tricking victims into downloading malicious code. The vulnerability affects all versions before 15.10.8, all versions starting from 15.11 before 15.11.7, and all versions starting from 16.0 before 16.0.2 [1].
Exploitation
An attacker with at least Guest access to a project can create a branch with a name that matches a protected tag pattern (e.g., v1). Since branch creation is not restricted by tag protection rules, the attacker can push arbitrary code to that branch. A victim may mistakenly believe the branch is a legitimate protected tag and download or execute its contents [1].
Impact
Successful exploitation can lead to a victim downloading malicious code, potentially resulting in arbitrary code execution, data exfiltration, or other compromise depending on the nature of the malicious payload.
Mitigation
Users should upgrade to GitLab 15.10.8, 15.11.7, or 16.0.2, which contain the fix. No workaround is available [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: <15.10.8, >=15.11 <15.11.7, >=16.0 <16.0.2
- Range: >=0.0, <15.10.8
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing normalization of tag names against protection rules allows an attacker to bypass protected tag restrictions by using the full ref path as the tag name."
Attack vector
An attacker with at least Developer-level access to a project can bypass protected tag rules by creating a tag whose name includes the full ref prefix (e.g., `refs/tags/v1`) instead of just the short tag name (e.g., `v1`). The tag protection rule (e.g., `v*`) is not matched against the full ref path, so the tag is created despite the attacker lacking Maintainer permissions. Although the tag link returns a 404, the "Download source code" feature resolves the tag reference by falling back to the content of a branch with the same name (e.g., branch `v1`), potentially tricking a victim into downloading malicious code from the attacker-controlled branch [ref_id=1].
Affected code
The vulnerability exists in GitLab's tag creation and protection logic. The issue is that when a user creates a tag with the name `refs/tags/v1` (which includes the full ref path), GitLab's tag protection rules (e.g., `v*`) are bypassed because the system does not properly normalize or validate the tag name against the protection pattern before creation. The advisory does not specify exact file paths or functions.
What the fix does
The advisory does not include a published patch diff. Based on the issue description, the fix would require GitLab to normalize or validate the tag name against protection rules by stripping the `refs/tags/` prefix before matching, or by rejecting tag names that contain the full ref path. The remediation should ensure that tag protection rules like `v*` are correctly applied regardless of whether the user supplies a short name or a full ref path [ref_id=1].
Preconditions
- authAttacker must have at least Developer-level access to the target GitLab project
- configThe project must have a protected tag rule (e.g., v*) that restricts tag creation to Maintainers
- inputAttacker must create a branch with the same short name as the intended tag (e.g., branch v1)
Reproduction
1. As victim (Maintainer), create a private project, invite the attacker as a member, and set a protected tag rule `v*` with "Allowed to create: Maintainers". 2. As attacker, create a branch named `v1` containing malicious content. 3. As attacker, go to Repository > Tags, click "New Tag", set the tag name to `refs/tags/v1` and "Create from" to branch `v1`, then create the tag. 4. A 404 page appears but the tag is created and appears as "protected" in the tags list. 5. The "Download source code" feature for this tag serves the content of branch `v1` 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