GHSA-pg62-f8g4-4wqh

## Overview When phpMyFAQ hardened its admin permission-assignment endpoints against privilege escalation, it added a "a non-SuperAdmin may only assign rights they themselves hold" constraint to the user-rights endpoint (`UserController::updateUserRights`). **The equivalent group-rights endpoint, `GroupController::updatePermissions`, did not receive that constraint.** A delegated administrator holding only the `GROUP_EDIT` permission can therefore grant any group an arbitrary set of rights — including rights the administrator does not possess — and, by being (or becoming) a member of that group, inherit those rights, escalating to higher privileges up to full administrative control. ## Impact phpMyFAQ supports delegated administration: the `GROUP_EDIT` right can be granted to a non-SuperAdmin so they can manage groups. Such an administrator can escalate: 1. They call `POST /admin/group/update/permissions` with `group_id` set to a group they belong to (or can manage membership of) and `group_rights[]` containing high-value rights they do **not** themselves hold (e.g. user administration, or any right gating sensitive actions). 2. The endpoint grants every requested right to the group with no check that the caller holds them. 3. Members of that group — including the attacker — inherit the granted rights, escalating the attacker's effective privileges. This is the group-side mirror of exactly what the maintainers blocked on the user-rights side, where the code comment names the threat explicitly ("prevents an administrator with the delegable USER_EDIT right from granting privileges they do not possess (privilege escalation)"). The group path remains open. `PR:L` (the attacker needs the delegable `GROUP_EDIT` right, below SuperAdmin), `S:U` (escalation within phpMyFAQ's single authorization authority), `C:H/I:H/A:H` (inherited rights can reach full administrative read/write/availability control). The one added step versus the user-rights path — the attacker must b