Incorrect Privilege Assignment in GitLab

An attacker who has been assigned a custom role with `admin_group_member` permission (based on Guest) can escalate to Owner of the target group. The attacker first creates their own group where they are Owner. Then, using the "Invite group" feature on the target group, they invite their own group with the "Owner" role. Because the fix for CVE-2023-6396 only restricted inviting individual users at a higher role, the group invitation path was left unrestricted [ref_id=1]. The attacker can also change an existing group member's role to Owner directly. This results in privilege escalation from a low-privilege custom role to full group Owner.

The vulnerability exists in the group membership invitation logic. When a user with a custom role that includes the `admin_group_member` permission (based on Guest) invites a group (rather than an individual user) to the target group, the system does not enforce the same role-level restriction that was applied to individual user invitations in the CVE-2023-6396 fix. The issue is tracked in GitLab issue #433463 [ref_id=1].

The advisory does not include a published patch diff, but the expected fix is described in the issue: custom roles should only be allowed to invite groups at a role level at or below their own maximum permitted role, mirroring the restriction already applied to individual user invitations [ref_id=1]. The fix was released in GitLab EE versions 16.7.6, 16.8.3, and 16.9.1. No patch diff is available in the bundle.

1. As victim_user, create a private Ultimate group and a custom role based on Guest with `admin_group_member` checked. Invite attacker_user as that custom role. 2. As attacker_user, create a new group called `attacker_group`. 3. Navigate to the target group's member page, click "Invite group", search for `attacker_group`, select it, and set the role to `Owner`. Click invite. 4. Refresh the page — attacker_user is now Owner of the target group [ref_id=1].