CVE-2020-13357
Description
An issue was discovered in Gitlab CE/EE versions >= 13.1 to <13.4.7, >= 13.5 to <13.5.5, and >= 13.6 to <13.6.2 allowed an unauthorized user to access the user list corresponding to a feature flag in a project.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
GitLab 13.1–13.6.2 allows an unauthenticated user to enumerate feature flag user lists (including user IDs) via a missing access control check on the user_list_id parameter.
Vulnerability
An Insecure Direct Object Reference (IDOR) vulnerability exists in GitLab Community Edition (CE) and Enterprise Edition (EE) versions 13.1.0 through 13.4.7, 13.5.0 through 13.5.5, and 13.6.0 through 13.6.2. The /feature_flags API endpoint fails to verify that the requesting user belongs to the project when a user_list_id parameter is supplied. As a result, an unauthenticated attacker can supply a sequential numeric user_list_id to retrieve the user list (including user IDs) associated with any feature flag in any public or private project. The issue was reported via HackerOne and tracked as #241132 [1].
Exploitation
The attacker requires no authentication and no prior access to the target project. By sending a crafted PUT request to the endpoint /-/feature_flags/{id} with a modified user_list_id parameter (a two-digit sequential ID, or any valid user list ID), the server returns the user list corresponding to that ID. The request can be made directly from a browser or a tool like curl without any session cookies. The attacker can then iterate through user list IDs to enumerate all such lists in the GitLab instance [1].
Impact
Successful exploitation allows an attacker to obtain the list of users (including their numeric user IDs) assigned to any feature flag's user list in any project, including private projects. This constitutes an information disclosure that can be used to map user accounts, identify project membership, and potentially aid further targeted attacks. The vulnerability does not grant write access or direct privilege escalation but exposes sensitive project and user metadata [1].
Mitigation
GitLab released fixed versions 13.4.7, 13.5.5, and 13.6.2 on 2020-10-28. Users running affected versions should upgrade immediately to one of the patched releases. No workaround is available for unpatched instances, and the vulnerability is not listed on CISA KEV. GitLab has credited the reporter and closed the associated issue in the public tracker [1].
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3>=13.1, <13.4.7 || >=13.5, <13.5.5 || >=13.6, <13.6.2+ 1 more
- (no CPE)range: >=13.1, <13.4.7 || >=13.5, <13.5.5 || >=13.6, <13.6.2
- (no CPE)range: >= 13.1 to <13.4.7
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing authorization check on the `user_list_id` parameter allows enumeration of feature flag user lists across projects."
Attack vector
An attacker can enumerate feature flag user lists by supplying sequential 2-digit IDs in the `user_list_id` parameter of a PUT request to the feature flags endpoint (e.g., `/-/feature_flags/1`). The server returns the name of the user list even when the list belongs to a private project, without checking project membership or authorization [ref_id=1]. This is an Insecure Direct Object Reference (IDOR) vulnerability — the attacker simply changes the numeric ID and observes the response.
Affected code
The vulnerability exists in the feature flags user list endpoint. The issue is that the endpoint accepts a `user_list_id` parameter (a sequential 2-digit ID) without verifying that the requesting user has access to the project that owns the feature flag user list [ref_id=1].
What the fix does
The advisory does not include a patch diff, but the expected correct behavior is described: "If feature flag user list belongs to private project, you should not be able to get the name of it" [ref_id=1]. The fix would require adding an authorization check on the `user_list_id` parameter to verify that the requesting user has access to the project that owns the referenced user list before returning its name.
Preconditions
- authAttacker must be an authenticated GitLab user (able to send PUT requests with a valid CSRF token)
- configAttacker must have access to at least one project with feature flags enabled to obtain the endpoint structure
- inputThe target feature flag user list must have a low, sequential numeric ID (2 digits) that can be guessed or enumerated
Reproduction
1. Go to `https://gitlab.com/<NameSpace>/project_1/-/feature_flags` and edit an existing feature flag. 2. In the "Type" dropdown, select "User List" and choose an available user list, then save. 3. Capture the PUT request (e.g., to `/-/feature_flags/1`) containing the `user_list_id` parameter. 4. Change the `user_list_id` value to any other sequential 2-digit ID and send the request. 5. Observe the name of the user list returned in the response, even if it belongs to a private project [ref_id=1].
Generated on May 25, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3- gitlab.com/gitlab-org/cves/-/blob/master/2020/CVE-2020-13357.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/241132mitrex_refsource_MISC
- hackerone.com/reports/962408mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.