CVE-2022-2456
Description
An issue has been discovered in GitLab CE/EE affecting all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, all versions starting from 15.2 before 15.2.1. It may be possible for malicious group or project maintainers to change their corresponding group or project visibility by crafting a malicious POST request.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Group or project maintainers can change visibility settings via crafted POST requests in GitLab CE/EE before versions 15.0.5, 15.1.4, and 15.2.1.
Vulnerability
A vulnerability in GitLab CE/EE affects all versions before 15.0.5, all versions starting from 15.1 before 15.1.4, and all versions starting from 15.2 before 15.2.1. It allows a malicious group or project maintainer to change the visibility level of a group or project by crafting a malicious POST request. The issue lies in the UpdateVisibilityLevel service and the Gitlab::VisibilityLevel module, where the level_value method returns 0 (PRIVATE) for any unrecognized input. For a private project or group, passing '20r' as the new visibility level causes level_value to return 0, which equals the current visibility level (PRIVATE), bypassing the permission check that would otherwise restrict maintainers from changing visibility [1].
Exploitation
An attacker who is a maintainer of a group or project can craft a POST request to the update endpoint, setting the visibility parameter to a value such as 20r. This value is not 'private', '10', '20', or 'internal'/'public', so level_value returns 0 (PRIVATE). Since the current visibility of a private project is also 0, the check new_visibility_level != target.visibility_level_value evaluates to false, and the permission check (can?(:change_visibility_level, ...)) is skipped entirely [1]. This allows the attacker to change the visibility to something else in subsequent steps, effectively promoting a private project to internal or public without authorization.
Impact
A successful attack allows a maintainer to change the visibility of a group or project to a higher level (e.g., from private to public). This can lead to unintended disclosure of sensitive project data, including source code, issues, merge requests, and wikis, to unauthorized users. The attacker gains no additional privileges within the system but can affect the confidentiality of the target group or project [1].
Mitigation
GitLab has addressed this issue in versions 15.0.5, 15.1.4, and 15.2.1. Users should upgrade to these or later versions immediately. There is no known workaround for unpatched instances. The issue was reported via HackerOne and tracked in GitLab issue #359910 [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- Range: >=15.0, <15.0.5 || >=15.1, <15.1.4 || >=15.2, <15.2.1
- Range: >=15.2, <15.2.1
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The `level_value` method returns 0 (PRIVATE) for malformed input strings, causing the permission check to be bypassed when the current visibility is also private, while the raw string's `.to_i` value is used to set the actual visibility."
Attack vector
A malicious group or project maintainer sends a crafted POST request to the project or group settings page, including a malformed `project[visibility_level]` parameter such as `20r` [ref_id=1]. The `level_value` method converts this to 0 (PRIVATE), which matches the current visibility level of a private project, so the permission check (`can?(:change_visibility_level)`) is skipped [ref_id=1]. The raw value `20r` is then parsed by `.to_i` to 20 (PUBLIC), and the project visibility is changed to public without authorization [ref_id=1]. The same technique works for groups and for other visibility transitions (e.g., `10r` for internal) [ref_id=1].
Affected code
The vulnerability resides in the `valid_visibility_level_change?` method in `app/services/concerns/update_visibility_level.rb` and the `level_value` method in `lib/gitlab/visibility_level.rb` [ref_id=1]. The `level_value` method returns 0 (the value of PRIVATE) for any unrecognized input string such as `"20r"`, causing the permission check to be bypassed when the current project is private [ref_id=1].
What the fix does
The advisory does not include a published patch diff, but the issue was fixed in GitLab versions 15.0.5, 15.1.4, and 15.2.1 [ref_id=1]. The fix likely ensures that the visibility level value is validated and sanitized before the inequality check, or that the permission check is performed unconditionally regardless of whether the new visibility appears equal to the current one [ref_id=1]. No further technical details of the patch are provided in the reference.
Preconditions
- authAttacker must be a Maintainer role on the target project or group
- networkAttacker must be able to send a crafted POST request to the project/group settings endpoint
- configThe target project or group must be private (visibility_level = 0) for the public/internal bypass, or public/internal for the private bypass
Reproduction
1. As victim, create a private project and invite the attacker as a Maintainer. 2. As attacker, navigate to Settings > General > Visibility, project features, permissions. 3. Intercept the POST request with Burp and add a form field `project[visibility_level]` with value `20r`. 4. Send the request; the project visibility changes to public [ref_id=1].
Generated on May 24, 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/2022/CVE-2022-2456.jsonmitrex_refsource_CONFIRM
- gitlab.com/gitlab-org/gitlab/-/issues/359910mitrex_refsource_MISC
- hackerone.com/reports/1536559mitrex_refsource_MISC
News mentions
0No linked articles in our index yet.