Improper Validation of Specified Type of Input in GitLab
Description
Denial of Service in pipelines affecting all versions of Gitlab EE and CE prior to 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1 allows attacker to cause pipelines to fail.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
An attacker with Developer role can cause pipelines to lose access to protected CI/CD variables, leading to pipeline failure in GitLab.
Vulnerability
CVE-2023-3917 is a Denial of Service vulnerability in GitLab Community Edition (CE) and Enterprise Edition (EE). It affects all versions prior to 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1. The bug occurs when a malicious developer pushes a tag named refs/heads/main pointing to the latest commit, which causes pipelines running on the main branch to lose access to protected CI/CD variables. Without access to these variables, pipeline jobs may fail, effectively denying service for legitimate pipeline execution [1].
Exploitation
To exploit this vulnerability, an attacker must have Developer role on a GitLab project. The attacker clones the project, deletes the .gitlab-ci.yml file, and creates a tag named refs/heads/main pointing to the latest commit hash. Pushing this tag triggers the pipeline to run without access to protected CI/CD variables, causing it to fail [1].
Impact
Successful exploitation results in pipeline failure due to missing protected variables. This constitutes a Denial of Service condition, preventing CI/CD pipelines from completing successfully and disrupting development workflows [1]. The attacker gains no direct code execution or data disclosure but can repeatedly cause pipeline failures.
Mitigation
GitLab released fixed versions: 16.2.8, 16.3.5, and 16.4.1 on September 29, 2023. Users should upgrade to one of these versions. No workaround is available for unpatched instances [1].
AI Insight generated on May 23, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: < 16.2.8, >= 16.3.0 < 16.3.5, >= 16.4.0 < 16.4.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Tag name collision with internal branch reference format (`refs/heads/main`) causes GitLab to misidentify the branch, denying access to protected CI/CD variables."
Attack vector
An attacker with Developer-level access to a GitLab project can create a tag named `refs/heads/main` pointing to the latest commit on the `main` branch [ref_id=1]. When a pipeline runs on `main`, GitLab confuses the tag with the branch reference, causing the pipeline to lose access to protected CI/CD variables that are scoped to the `main` branch [ref_id=1]. This causes pipelines to fail (Denial of Service) and also prevents project owners from deleting the malicious tag, as the tag name collides with the internal branch reference format [ref_id=1].
Affected code
The vulnerability is in GitLab's CI/CD pipeline logic that resolves protected variables and branch references. The issue involves how GitLab handles tag names that collide with branch references (e.g., a tag named `refs/heads/main`), causing the pipeline to lose access to protected CI/CD variables that are scoped to the actual `main` branch [ref_id=1].
What the fix does
The issue is tracked in GitLab issue #417896 [ref_id=1]. While no patch diff is included in the bundle, the advisory indicates this is a bypass of a previously fixed issue (issue #406843) [ref_id=1]. The fix would need to validate that tag names do not collide with internal reference formats (e.g., `refs/heads/...`) to prevent the confusion between tags and branch references that causes the protected variable access check to fail [ref_id=1].
Preconditions
- authAttacker must have Developer-level access to the GitLab project
- configProject must have at least one protected CI/CD variable configured
- inputAttacker must be able to push tags to the remote repository
Reproduction
1. As an owner, create a project, add a protected CI/CD variable, and add a `.gitlab-ci.yml` that prints the variable. Add a developer to the project. 2. As the developer, clone the project, delete `.gitlab-ci.yml`, commit, and get the commit hash. 3. Create a tag named `refs/heads/main` pointing to that commit hash and push it. 4. As the owner, run a new pipeline on `main` and observe that the protected variable is not printed and the pipeline fails [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- hackerone.com/reports/2055158mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/417896mitreissue-trackingpermissions-required
News mentions
1- GitLab Security Release: 16.4.1, 16.3.5, and 16.2.8GitLab Security Releases · Sep 28, 2023