GitLab EE: pending members receive custom-role permissions before their membership is active

Impact

Incorrect privilege assignment does not account for membership state, so a user whose membership is still pending can receive the permissions granted by a custom role. On a self-managed GitLab that gates access to fleet CI/CD and artifact registries, that means the approval step operators rely on before granting access is not the point at which access actually starts. GitLab rates it 3.3 with high privileges and high attack complexity required, and describes low confidentiality and integrity impact - the granted permissions are whatever the custom role carries, which the record does not enumerate. Affects 15.6 before 19.0.6, 19.1 before 19.1.4 and 19.2 before 19.2.2.

Who can reach it

A user with a pending membership on a group or project where a custom role is assigned; exploitation additionally requires high privileges elsewhere in the instance per GitLab's scoring. Network access to the instance is required.

What to do

Upgrade to 19.0.6, 19.1.4 or 19.2.2 per the GitLab 19.2.2 patch release - a package upgrade and service restart (Omnibus reconfigure/restart or a Helm chart bump), no node drain. Afterwards, audit pending memberships attached to custom roles and confirm no access was exercised before approval.

References