Privilege Chaining in GitLab
Description
An issue has been discovered in GitLab EE affecting all versions starting from 16.8 before 16.8.2. When a user is assigned a custom role with manage_group_access_tokens permission, they may be able to create group access tokens with Owner privileges, which may lead to privilege escalation.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A user with a custom role having manage_group_access_tokens permission can create group access tokens with Owner privileges, leading to privilege escalation in GitLab EE 16.8.0 and 16.8.1.
Vulnerability
GitLab EE versions 16.8.0 and 16.8.1 are affected by a privilege escalation vulnerability [1]. A user who is assigned a custom role with the manage_group_access_tokens permission can create group access tokens (GATs) with Owner-level privileges, even if their base role is only Guest [1]. This allows the user to elevate their privileges within the group beyond what was intended.
Exploitation
An attacker needs to have a GitLab account that is a member of a group and has been assigned a custom role with the base role of Guest and a custom permission of manage_group_access_tokens [1]. The attacker can then create a group access token from the UI or via the REST API, specifying the token's access level as Owner [1]. After creating the token, the attacker can use it to perform actions with Owner privileges, effectively escalating their own privileges within the group.
Impact
Successful exploitation allows the attacker to gain Owner-level access to the group, which includes the ability to manage group members, change group settings, delete the group, and access all projects within the group [1]. This represents a significant privilege escalation, as the attacker started with only Guest (read-only) access.
Mitigation
GitLab has released version 16.8.2 which fixes this vulnerability [1]. Users are advised to upgrade their GitLab EE instance to version 16.8.2 or later immediately. There is no known workaround for this issue; updating is the only mitigation. The vulnerability is not listed on CISA's Known Exploited Vulnerabilities catalog.
AI Insight generated on May 24, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=16.8, <16.8.2
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing access-level validation when creating group access tokens allows a user with a custom role (base Guest, permission manage_group_access_tokens) to create tokens with Owner privileges."
Attack vector
An attacker who has been assigned a custom role with base role Guest and the manage_group_access_tokens permission can create a Group Access Token (GAT) with the Owner access level via the UI or the REST API [ref_id=1]. The attacker then uses that Owner-level token to perform any privileged action within the group, effectively escalating from Guest to Owner [ref_id=1]. The bug is triggered by sending a request to the group access token creation endpoint without the server validating that the token's access level does not exceed the creator's own effective access level [ref_id=1].
Affected code
The advisory does not specify exact file paths or function names. The vulnerability exists in the group access token creation logic, both in the UI and the REST API endpoint documented at /api/v4/groups/:id/access_tokens [ref_id=1]. The advisory notes that corresponding GraphQL endpoints may also be affected [ref_id=1].
What the fix does
No patch is included in the bundle, but the advisory proposes a fix analogous to a previous issue: a user with a custom role should only be able to create a GAT with an access level less than or equal to their own access level, capped at Maintainer if their base role is Maintainer [ref_id=1]. The fix must be applied both in the UI and the REST API (and possibly GraphQL) endpoints that handle GAT creation [ref_id=1].
Preconditions
- configThe attacker must be assigned a custom role with base role Guest and the manage_group_access_tokens permission in the target group.
- networkThe attacker must have network access to the GitLab instance's UI or REST API.
Reproduction
1. Create an instance-level custom role with base role Guest and the manage_group_access_tokens permission. 2. Assign this role to a group member via Rails console: `group = Group.find_by_full_path('group-path'); member = group.members.find_by(user_id: user-id); member.update(member_role: MemberRole.last)`. 3. Log in as that user and create a Group Access Token with the Owner role via the UI or via a REST API call to the group access tokens creation endpoint. 4. Verify the Owner-level token works by making API calls with it (e.g., `curl -H "PRIVATE-TOKEN: <token>" https://gdk.test:3443/api/v4/groups/98/members/all | jq`) [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1- gitlab.com/gitlab-org/gitlab/-/issues/439175mitreissue-trackingpermissions-required
News mentions
1- GitLab Security Release: 16.8.2, 16.7.5, 16.6.7GitLab Security Releases · Feb 7, 2024