# phpMyFAQ privilege escalation: GroupController::updatePermissions lets a GROUP_EDIT admin grant rights they do not hold

phpMyFAQ's GroupController::updatePermissions lacked the self-rights check its user-rights sibling had, letting a GROUP_EDIT admin grant their group rights they don't hold and inherit them.

- Payout: Research
- Severity: high
- Program: phpMyFAQ
- Found by: Yanchon918s
- Disclosed: 2026-08-25
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-pg62-f8g4-4wqh
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-pg62-f8g4-4wqh
- Tags: area:web domain:web impact:integrity impact:privesc kind:research platform:ghsa sev:high tech:php technique:incomplete-fix technique:source-review vuln:access-control vuln:privilege-escalation

**Target:** POST /admin/group/update/permissions admin endpoint (GroupController)
**Root cause:** updatePermissions only gates on userHasPermission(GROUP_EDIT) and grants every attacker-supplied group_rights[] entry verbatim; the 'non-SuperAdmin may only assign rights they hold' loop added to UserController::updateUserRights was never applied to the group path.
**Steps:**
1. Create a non-SuperAdmin account with GROUP_EDIT, member of group G (id 2).
2. Log in as that admin and grab the update-group-permissions CSRF token.
3. POST `/admin/group/update/permissions` with `pmf-csrf-token`, `group_id=2`, and `group_rights[]=1` (a RIGHT_ID the admin lacks).
4. Response reports `ad_msg_savedsuc_*`; confirm `SELECT * FROM faqgroup_right WHERE group_id=2` contains the new right_id.
5. As a member of G, exercise the inherited right; the same attempt against updateUserRights returns 403 msgNoPermission.
**How found:** Audited the completeness of the GHSA-xvp4/GHSA-985r/GHSA-8c6h admin-API authorization-hardening series at HEAD 04db2b999d8d; noticed the self-rights constraint added to updateUserRights had no counterpart on the GroupController::updatePermissions sibling by reading both handlers, the permission gate and the grantGroupRight sink.
**Exploitation:** A delegated GROUP_EDIT administrator targets a group they belong to (or add themselves, since GROUP_EDIT generally covers membership), submits arbitrary right IDs to the group-permissions endpoint, and inherits the granted rights as a group member — escalating up to full administrative control.
**Escalation:** Granting high-value rights (e.g. user administration) to an owned group converts a delegable GROUP_EDIT role into full admin read/write/availability control.
**Insight:** When maintainers patch a privilege-escalation class on one endpoint, enumerate every sibling handler that reaches the same grant sink (user rights vs group rights) — the fix is usually applied only where the report pointed, leaving the mirror path open.