AI analysis
GitLab Enterprise Edition did not properly clean up scheduled pipeline execution policy records when a project was transferred between groups. Under certain conditions, an authenticated user could then run arbitrary CI/CD pipelines in that transferred project with the destination group's privileges (CWE-863, incorrect authorization). The issue is network-reachable but high complexity, needs low privileges and user interaction, and can expose or alter data with changed scope; availability is not affected (CVSS 3.1 base 7.7). It affects GitLab EE from 18.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. It is not on the CISA KEV list and no public proof-of-concept is known.
What to do: Upgrade self-managed GitLab EE to 19.2.8, 19.3.5, or 19.4.2 (or a later release in that line). After upgrading, review recently transferred projects for leftover scheduled pipeline execution policy records and audit CI/CD jobs that ran under the destination group's privileges. Limit who can transfer projects until instances are patched.
Affected
| GitLab EE | 18.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 |
Estimated exposure
largeon the order of 10,000+ self-managed GitLab EE instances, plausibly 100,000+ users (estimate) — Order-of-magnitude estimate from GitLab EE being a widely deployed paid enterprise DevOps platform; only self-managed EE in the stated version ranges is affected, not GitLab CE, and no install-count or scan figure is in the advisory.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
GitLab has remediated an issue in GitLab EE affecting all versions from 18.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user to execute arbitrary CI/CD pipelines in a transferred project with the new group's privileges due to improper cleanup of scheduled pipeline execution policy records.