Database/Control plane, storage & DevOps

GitLab EE: stale pipeline execution policies run CI/CD with the new group's privileges after project transfer

CVSS 7.7CVE-2026-81839Control plane, storage & DevOpscurated

Impact

Scheduled pipeline execution policy records are not cleaned up when a project is transferred, so an authenticated user can get arbitrary CI/CD pipelines executed in the transferred project carrying the new group's privileges. The practical effect is that a pipeline defined under a low-trust group keeps running after the project moves into a higher-trust one, inheriting that group's runners and variables. In a datacenter where group hierarchy is how automation privilege is separated - build groups versus fleet-provisioning groups - a project transfer silently becomes a privilege grant. Requires high attack complexity and user interaction per the vector.

Who can reach it

An authenticated GitLab EE user involved with a project that is transferred between groups; the vector also requires user interaction, so a legitimate transfer or action by another user is part of the path.

What to do

Upgrade GitLab EE to 19.2.8, 19.3.5 or 19.4.2. Versions from 18.1 are affected. Application upgrade and restart. Operators who have transferred projects between groups should also audit existing scheduled pipeline execution policies on those projects after upgrading, since the leftover records are what the flaw depends on.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-81839 https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/https://gitlab.com/gitlab-org/gitlab/-/work_items/624150 https://hackerone.com/reports/3925062

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.