CVE-2023-0805
Description
An issue has been discovered in GitLab EE affecting all versions starting from 15.2 before 15.9.6, all versions starting from 15.10 before 15.10.5, all versions starting from 15.11 before 15.11.1. A malicious group member may continue to have access to the public projects of a public group even after being banned from the public group by the owner.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Banned GitLab group members retain their original access level to public projects of a public group, bypassing the restriction.
Vulnerability
GitLab EE versions 15.2 through 15.9.6, 15.10 before 15.10.5, and 15.11 before 15.11.1 fail to enforce group bans on public projects within a public group. When a group owner bans a member, the member loses access only to private projects, but retains their previous access level (e.g., Maintainer) to all public projects of that group. This affects all EE versions starting from 15.2 where the group ban feature was introduced [1].
Exploitation
An attacker must be a member of a public GitLab group (requires Ultimate or Premium license) and have been granted any access level (e.g., Guest, Reporter, Developer, Maintainer, Owner). The group owner or admin bans the attacker from the group. The attacker then logs in and accesses any public project within the same group, where they retain the full privileges of their previous role. No additional authentication or complex steps are required beyond normal group membership and the ban event [1].
Impact
A banned malicious group member can continue to view, modify settings, push code, or perform any actions allowed by their original access level on public projects of the group. This undermines the group ban feature and can lead to unauthorized data exposure, project manipulation, or privilege escalation within public projects, potentially enabling further attacks [1].
Mitigation
GitLab has fixed the issue in versions 15.9.6, 15.10.5, and 15.11.1. Users should upgrade immediately to one of these patched versions. No workarounds are documented; affected instances cannot restrict banned members from public projects without upgrading. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog as of this writing [1].
AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
3- Range: >=15.2, <15.9.6 || >=15.10, <15.10.5 || >=15.11, <15.11.1
- Range: >=15.2, <15.9.6
Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The ban enforcement logic fails to revoke the banned member's existing project membership on public projects within the group."
Attack vector
An attacker who is a member of a public GitLab group (Ultimate/Premium tier) can be banned by the group owner but retain their previous access level (e.g., maintainer) on the group's public projects. The attacker simply continues to access those public projects after being banned; the ban only removes access to private projects [ref_id=1]. No special payload or network manipulation is required — the attacker only needs to have been a group member before the ban.
What the fix does
The advisory does not include a published patch diff, but the fix addresses the gap where banning a group member only removed their access to private projects while leaving their existing project-level membership intact on public projects [ref_id=1]. The remediation ensures that when a user is banned from a group, their direct project memberships on all projects within that group — including public ones — are also revoked. Without this fix, a banned member retains the same access level they had before the ban on public projects.
Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.