phpMyFAQ - Privilege Escalation via Missing Authorization in editUser() and updateUserRights()

An authenticated administrator who holds the delegable `edit_user` permission — but is not a SuperAdmin — can escalate privileges by sending a crafted request to `admin/api/user/edit` with `is_superadmin` set to `true`, causing the server to flip the actor's own `is_superadmin` flag to `1` [ref_id=1]. The same attacker can also call `admin/api/user/update-rights` to grant arbitrary rights (e.g. `editconfig`) to any account [ref_id=1]. The only gate on both endpoints is `userHasPermission(PermissionType::USER_EDIT)`, which the attacker already possesses. The attacker needs a valid authenticated session and a CSRF token, both of which are available to an authenticated admin [ref_id=1]. This is a classic case of missing authorization (CWE-862) and improper privilege management (CWE-269) [ref_id=1].

The vulnerability resides in `editUser()` and `updateUserRights()` methods within `phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/UserController.php`. The `editUser()` method (lines 419-476) accepts a user-controlled `is_superadmin` parameter and passes it to `$user->setSuperAdmin()` without checking whether the actor is a SuperAdmin. Similarly, `updateUserRights()` (lines 482-520) calls `grantUserRight()` with a user-controlled `userId` and right ID. Both endpoints only gate on `userHasPermission(PermissionType::USER_EDIT)`, which a non-SuperAdmin administrator can hold. The `setSuperAdmin()` method in `phpmyfaq/src/phpMyFAQ/User.php` (lines 950-962) performs no authorization check of its own.

The advisory recommends applying the same authorization invariant that was added to `overwritePassword()` in the 4.1.3 fix to the sibling endpoints [ref_id=1]. For `editUser()`, the fix must reject changes to `is_superadmin`, `status`, or 2FA fields unless the current user is a SuperAdmin, and must never allow a non-SuperAdmin to edit a SuperAdmin or protected target [ref_id=1]. For `updateUserRights()`, the fix must require `isSuperAdmin()` (or a privilege-level comparison) before calling `grantUserRight()`, forbid granting rights the actor does not itself hold, and forbid targeting SuperAdmin or protected users [ref_id=1]. The advisory notes that the 4.1.3 patch only touched `overwritePassword()` and `deleteUser()`, leaving these two methods unguarded [ref_id=1].