Loop with Unreachable Exit Condition ('Infinite Loop') in GitLab
Description
An issue has been discovered in GitLab CE/EE affecting all versions starting from 16.2 before 16.3.6, all versions starting from 16.4 before 16.4.2, all versions starting from 16.5 before 16.5.1. A low-privileged attacker can point a CI/CD Component to an incorrect path and cause the server to exhaust all available memory through an infinite loop and cause Denial of Service.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A low-privileged attacker can cause denial of service via memory exhaustion in GitLab CE/EE by pointing a CI/CD Component to an incorrect path.
Vulnerability
An infinite loop in GitLab CE/EE's CI/CD Component path resolution allows a low-privileged attacker to exhaust server memory. The bug affects self-hosted instances running versions 16.2.0 through 16.3.5, 16.4.0 through 16.4.1, and 16.5.0. When a pipeline is triggered with a .gitlab-ci.yml that sets CI_CATALOG_PATH (an undefined variable) instead of CI_PROJECT_PATH, the server enters an infinite loop, consuming all available memory until the process is killed by the out-of-memory (OOM) killer [1].
Exploitation
An attacker with at least Developer role on a self-hosted GitLab instance can reproduce the issue by creating a new repository, pushing a copy of the emoji-ops/gitlab-ci project (or any project with a CI configuration), then editing .gitlab-ci.yml to replace CI_PROJECT_PATH with CI_CATALOG_PATH. After committing and pushing the change, the attacker runs a pipeline from the Run Pipeline UI. The server immediately begins allocating memory in an unbounded loop, leading to a crash within seconds [1].
Impact
Successful exploitation causes a complete denial of service: the GitLab omnibus process exhausts all available system memory and is terminated by the OOM killer. No data is corrupted or disclosed, and no code execution is achieved. The service becomes unavailable until manually restarted [1].
Mitigation
GitLab has released fixed versions: 16.3.6, 16.4.2, and 16.5.1. All users running an affected version should upgrade immediately. No workaround is available for unpatched instances. This vulnerability is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog as of publication [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, <16.3.6; >=16.4, <16.4.2; >=16.5, <16.5.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing input validation in CI/CD Catalog path resolution causes an infinite loop when an undefined variable (`CI_CATALOG_PATH`) is referenced instead of the correct `CI_PROJECT_PATH`."
Attack vector
A low-privileged attacker with the ability to push commits to a repository on a self-hosted GitLab instance can trigger this vulnerability. The attacker creates or pushes a repository containing a `.gitlab-ci.yml` file that references `CI_CATALOG_PATH` (an undefined variable) instead of the correct `CI_PROJECT_PATH` [ref_id=1]. When a pipeline is run from the UI, the CI/CD Catalog component attempts to resolve this path and enters an infinite loop, causing memory consumption to grow until the server runs out of memory (OOM) and crashes [ref_id=1].
Affected code
The vulnerability lies in the CI/CD Catalog component's handling of the `CI_CATALOG_PATH` variable. When a user sets `CI_CATALOG_PATH` (which is not a defined/supported variable) instead of `CI_PROJECT_PATH` in `.gitlab-ci.yml`, the system enters an infinite loop during pipeline execution, exhausting memory [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the issue was addressed in GitLab versions 16.3.6, 16.4.2, and 16.5.1 [ref_id=1]. The fix likely involves adding input validation or bounds checking to the CI/CD Catalog path resolution logic to prevent infinite loops when an undefined or incorrect path variable like `CI_CATALOG_PATH` is supplied. Users should upgrade to the patched versions to remediate the vulnerability.
Preconditions
- authAttacker must have a user account on a self-hosted GitLab instance (low privilege)
- inputAttacker must be able to create a repository and push commits with a modified .gitlab-ci.yml
- configThe instance must be running GitLab CE/EE versions 16.2 through 16.3.5, 16.4.0-16.4.1, or 16.5.0
Reproduction
1. On a self-hosted GitLab instance, create a new repository. 2. Clone https://gitlab.com/emoji-ops/gitlab-ci and push it to the new repository (master was b4cb8e996e03cd when this happened). 3. Create a branch. 4. Edit `.gitlab-ci.yml` and change `CI_PROJECT_PATH` to `CI_CATALOG_PATH` (which isn't set and doesn't exist). 5. Commit and push to the repository. 6. Go to the Run Pipeline UI and click run. 7. Memory usage will increase until the server runs out of memory (OOM) and crashes [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/2218566mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/428984mitreissue-trackingpermissions-required
News mentions
1- GitLab Security Release: 16.5.1, 16.4.2, 16.3.6GitLab Security Releases · Oct 31, 2023