# Removing a user from a private group doesn't remove him from group's project, if his project's role was changed

Removing a user from a private GitLab group left them with access to projects where their per-project role had been changed.

- Payout: hidden
- Severity: medium
- Program: GitLab
- Found by: rpadovani
- Disclosed: 2019-04-05
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/310185
- Library page: https://bugbountylibrary.com/r/h1%3A310185
- Tags: area:web domain:web impact:data-leak impact:internal-access kind:bounty platform:hackerone sev:medium tech:rest vuln:access-control vuln:auth-bypass

**Target:** GitLab group/project membership management
**Root cause:** Group membership removal does not revoke or reconcile per-project membership overrides, so a user with a separately-set project role retains access after leaving the group.
**Steps:**
1. Admin creates a private group with several projects.
2. Admin adds user as master of the group.
3. User changes their own role in individual projects (e.g. lowers privileges).
4. Admin removes the user from the group's members.
5. User still has access to the projects where their role was changed; admin sees no warning.
**How found:** Researcher was removed from a group as developer but was master of some projects and still had access, revealing the mismatch between group and project membership.
**Exploitation:** A user with a group role edits their per-project membership, then after being removed from the group retains access to those projects' resources because project-level membership persists.
**Insight:** When testing membership/ACL systems with inherited roles, check whether per-resource role overrides survive removal from the parent container; test self-demotion in child resources before parent removal.