Incorrect User Management in GitLab
Description
A business logic error in GitLab EE affecting all versions prior to 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1 allows access to internal projects. A service account is not deleted when a namespace is deleted, allowing access to internal projects.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab EE fails to delete service accounts when a namespace is deleted, allowing continued access to internal projects via orphaned accounts.
Vulnerability
A business logic error in GitLab EE affects all versions prior to 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1. When a namespace (group or subgroup) is deleted, the associated service accounts are not also deleted, leaving orphaned accounts that retain their existing permissions, including access to internal projects [1].
Exploitation
An attacker who can create a group and a service account (requires at least the Developer role in the group) can exploit this by performing the following steps: 1) Create a new group and note its ID. 2) Use the REST API (e.g., curl --request POST --header "PRIVATE-TOKEN: " "https://gitlab.example.com/api/v4/groups//service_accounts") to create a service account. 3) Create a personal access token for the service account. 4) Have the namespace deleted (either by the attacker themselves if they have Owner permissions, or by an administrator removing the user and their groups). After deletion, the service account remains active, allowing the attacker to access any internal projects the original group had access to [1].
Impact
An unauthorized attacker can gain access to internal projects within the GitLab instance. This can lead to disclosure of sensitive information, including source code, issues, and other project data that the orphaned service account could previously access. The attacker retains the same level of access as when the namespace existed, potentially bypassing namespace deletion intended to revoke access [1].
Mitigation
GitLab has addressed this issue in versions 16.2.8, 16.3.5, and 16.4.1. Users should upgrade to one of these patched versions immediately. As a temporary workaround, administrators should manually audit and delete any orphaned service accounts after deleting namespaces. No evidence of exploitation in the wild has been reported [1].
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.2.8, <16.3.5, <16.4.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing cascade deletion of service accounts when a namespace is deleted, leaving orphaned service accounts with active access tokens."
Attack vector
An attacker who owns a group on a GitLab instance creates a service account via the API, then generates a personal access token for that service account [ref_id=1]. After the attacker's group (namespace) is deleted — either by an admin or through group management — the service account and its token remain active. The attacker can then use the orphaned service account's token to access internal projects, since the service account retains its permissions despite the owning namespace being removed [ref_id=1].
Affected code
The vulnerability is a business logic error in GitLab EE's service account feature. When a namespace (group) is deleted, the associated service accounts are not deleted, leaving orphaned service accounts that continue to exist in the system [ref_id=1]. The issue is in the namespace deletion logic, which fails to cascade deletion to connected service accounts.
What the fix does
The advisory states that deleting a namespace should delete any connected service accounts [ref_id=1]. No patch diff is included in the bundle, but the remediation guidance is clear: the namespace deletion logic must be updated to cascade deletion to all service accounts associated with that namespace. This closes the vulnerability by ensuring orphaned service accounts cannot persist after their owning namespace is removed.
Preconditions
- configAttacker must have a group on a GitLab EE instance (unlimited trial on gitlab.com or self-hosted premium server)
- authAttacker must have an access token with sufficient permissions to create service accounts and delete groups
- inputThe instance must have internal projects accessible to group members
Reproduction
1. Create a new group and note its group ID. 2. Create a service account via API: `curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/<group_id>/service_accounts"` 3. Note the service account ID, then create a personal access token for it: `curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/<group_id>/service_accounts/<service_account_id>/personal_access_tokens" --data "scopes[]=api" --data "name=service_accounts_token"` 4. Verify the service account exists by querying the API with the new token: `curl --header "PRIVATE-TOKEN: <service_access_token>" "https://gitlab.example.com/api/v4/user"` 5. Delete the group via the group settings page (Advanced > Delete group). 6. Repeat step 4 — the service account still exists and can access internal projects [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- hackerone.com/reports/2040822mitretechnical-descriptionexploitpermissions-required
- gitlab.com/gitlab-org/gitlab/-/issues/418115mitreissue-trackingpermissions-required
News mentions
1- GitLab Security Release: 16.4.1, 16.3.5, and 16.2.8GitLab Security Releases · Sep 28, 2023