Vulnerability-Lookup

GHSA-PG62-F8G4-4WQH

Vulnerability from github – Published: 2026-08-25 17:32 – Updated: 2026-08-25 17:32

Summary

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

Details

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:

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).
The endpoint grants every requested right to the group with no check that the caller holds them.
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 be a member of the group they elevate (a GROUP_EDIT admin generally manages group membership, hence AC:L) — is noted in Technical Details.

Technical Details

References are to phpmyfaq/src/phpMyFAQ/ at HEAD 04db2b999d8d.

The vulnerable endpoint — no self-rights check (Controller/Administration/GroupController.php:309-349):

#[Route(path: '/group/update/permissions', name: 'admin.group.update.permissions', methods: ['POST'])]
public function updatePermissions(Request $request): Response
{
    $this->userHasPermission(PermissionType::GROUP_EDIT);     // only requires GROUP_EDIT — not SuperAdmin, no per-right check
    // ... CSRF verified ...
    $groupId = (int) Filter::filterVar($request->request->get('group_id'), FILTER_VALIDATE_INT);
    $groupPermissions = $request->request->all()['group_rights'];   // attacker-controlled list of right IDs

    $refuseResult = $this->user->perm->refuseAllGroupRights($groupId);
    if ($refuseResult) {
        foreach ($groupPermissions as $groupPermission) {
            $this->user->perm->grantGroupRight($groupId, (int) $groupPermission);   // grants ANY right, unconstrained
        }
        ...
    }
}

Each group_rights[] entry is granted to the group verbatim; there is no verification that the acting administrator holds that right.

The fixed sibling — updateUserRights DOES constrain to self-held rights (Controller/Administration/Api/UserController.php:558-579):

$actingIsSuperAdmin = $this->currentUser->isSuperAdmin();
// A non-SuperAdmin may only assign rights they hold themselves. This prevents an
// administrator with the delegable USER_EDIT right from granting privileges they do not
// possess (privilege escalation).
if (!$actingIsSuperAdmin) {
    $actingUserId = $this->currentUser->getUserId();
    foreach ($userRights as $userRight) {
        if (!$this->currentUser->perm->hasPermission($actingUserId, (int) $userRight)) {
            return $this->json(['error' => Translation::get(key: 'msgNoPermission')], Response::HTTP_FORBIDDEN);
        }
    }
}

The identical "may only assign rights you hold" loop is present for user rights but absent for group rights. The group endpoint's only gate is userHasPermission(GROUP_EDIT) (Controller/AbstractController.php/AbstractAdministrationController.php), which checks the caller holds GROUP_EDIT — not that they hold each right being granted. This is an authorization omission: the enforcer the maintainers already wrote for the analogous mass-assignment of rights is simply not applied on the group path.

Inheritance step (honest precondition). grantGroupRight grants the right to the group; the attacker realizes the escalation by being a member of the elevated group. A GROUP_EDIT administrator manages groups (and typically their membership), so they can target a group they already belong to or add themselves — keeping AC:L. If a given deployment separates group-membership management from GROUP_EDIT, the attacker is limited to elevating groups they already belong to, which is still the common case for a delegated group admin.

Reproduction

phpMyFAQ is self-hosted; reproduce on your own test instance. Create a non-SuperAdmin account granted GROUP_EDIT (and member of some group G), log in as it, and run in the DevTools Console:

// Run as the delegated (non-SuperAdmin) GROUP_EDIT admin, on the phpMyFAQ admin UI.
// Grant group G (a group the attacker belongs to) a right the attacker does NOT hold
// (use a numeric RIGHT_ID for a high-value permission the account lacks, e.g. user admin).
const csrf = document.querySelector('[name="pmf-csrf-token"], #pmf-csrf-token')?.value
  || window.PMF_CSRF_UPDATE_GROUP_PERMISSIONS;  // the update-group-permissions token rendered on the group page
const body = new URLSearchParams();
body.set("pmf-csrf-token", csrf);
body.set("group_id", String(/* G's group id */ 2));
body.append("group_rights[]", String(/* RIGHT_ID the attacker lacks */ 1));
fetch("/admin/group/update/permissions", { method: "POST", credentials: "include", body })
  .then((r) => r.text())
  .then((t) => console.log(t.includes("savedsuc") ? "GRANTED (200)" : t.slice(0, 200)));

Expected result: the response reports success (ad_msg_savedsuc_*), i.e. the right was granted to group G even though the acting admin does not hold it. Confirm with SELECT * FROM faqgroup_right WHERE group_id=2 (or the app's group-rights view) that the new right_id is present, then verify the attacker (a member of G) now exercises the inherited right. (Against updateUserRights the same attempt to assign an unheld right returns 403 msgNoPermission, demonstrating the missing constraint is specific to the group path.)

End-to-end (source) verification

Authorization-omission finding; the gap is open at HEAD and reaches the privilege-grant sink with no intervening per-right check:

Endpoint reachable by a delegated non-SuperAdmin: updatePermissions gate is userHasPermission(PermissionType::GROUP_EDIT) (:311) — confirmed it does not require SuperAdmin nor check the granted rights.
Attacker controls the granted rights: group_rights[] from the request body, granted in the loop at :329.
Missing control: the self-rights loop present in updateUserRights (UserController.php:563-571) has no counterpart in updatePermissions — verified by reading both handlers at HEAD.
Sink: MediumPermission::grantGroupRight -> INSERT INTO faqgroup_right (Permission repository), persisting the unheld right to the group; members of the group inherit it.

Suggested Fix

Apply the same self-rights constraint updateUserRights already has, before granting:

$actingIsSuperAdmin = $this->currentUser->isSuperAdmin();
if (!$actingIsSuperAdmin) {
    $actingUserId = $this->currentUser->getUserId();
    foreach ($groupPermissions as $groupPermission) {
        if (!$this->currentUser->perm->hasPermission($actingUserId, (int) $groupPermission)) {
            throw new UnauthorizedHttpException('Cannot grant a right you do not hold');
        }
    }
}

More robustly, factor the "you may only assign rights you hold" rule into the permission layer (grantGroupRight / grantUserRight) so both the user-rights and group-rights paths enforce it uniformly, and add a regression test mirroring testUpdateRightsNonSuperAdminCannotGrantRightTheyDoNotHold for the group endpoint. (See also the related sibling gaps in the same admin-API authorization series: UserController::addUser missing the acting-SuperAdmin guard, and the user/data / user/permissions target-authorization on read.)

Disclosure Timeline

2026-05-30: Discovered while auditing the completeness of the GHSA-xvp4 / GHSA-985r / GHSA-8c6h admin-API authorization-hardening series at main HEAD 04db2b999d8d. The self-rights constraint added to updateUserRights was confirmed absent on the GroupController::updatePermissions sibling by reading both handlers + the permission gate + the grantGroupRight sink.
2026-05-30: Drafted for submission via GitHub Security Advisory.

References

Hardening series this incompletely fixes: GHSA-xvp4-phqj-cjr3, GHSA-985r-q3qp-299h ("incomplete fix for GHSA-xvp4"), GHSA-8c6h-7g6x-m5x4 ("incomplete fix for CVE-2026-24421").
Affected source: phpmyfaq/src/phpMyFAQ/Controller/Administration/GroupController.php:309-349 (updatePermissions, gate userHasPermission(GROUP_EDIT) at :311, sink grantGroupRight at :329); fixed sibling Controller/Administration/Api/UserController.php:534-589 (updateUserRights, self-rights loop at :563-566); Controller/AbstractController.php:326-336 (userHasPermission, the only gate — GROUP_EDIT action permission).
Companion advisory (same audit, same series): user/add missing acting-SuperAdmin guard -> delegated admin creates SuperAdmin (8.8 High).

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyfaq/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "thorsten/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-25T17:32:07Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Overview\n\nWhen 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 \u2014 including rights the administrator does not possess \u2014 and, by being (or becoming) a member of that group, inherit those rights, escalating to higher privileges up to full administrative control.\n\n## Impact\n\nphpMyFAQ supports delegated administration: the `GROUP_EDIT` right can be granted to a non-SuperAdmin so they can manage groups. Such an administrator can escalate:\n\n1. 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).\n2. The endpoint grants every requested right to the group with no check that the caller holds them.\n3. Members of that group \u2014 including the attacker \u2014 inherit the granted rights, escalating the attacker\u0027s effective privileges.\n\nThis 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.\n\n`PR:L` (the attacker needs the delegable `GROUP_EDIT` right, below SuperAdmin), `S:U` (escalation within phpMyFAQ\u0027s 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 \u2014 the attacker must be a member of the group they elevate (a GROUP_EDIT admin generally manages group membership, hence `AC:L`) \u2014 is noted in Technical Details.\n\n## Technical Details\n\nReferences are to `phpmyfaq/src/phpMyFAQ/` at HEAD `04db2b999d8d`.\n\n**The vulnerable endpoint \u2014 no self-rights check (`Controller/Administration/GroupController.php:309-349`):**\n\n```php\n#[Route(path: \u0027/group/update/permissions\u0027, name: \u0027admin.group.update.permissions\u0027, methods: [\u0027POST\u0027])]\npublic function updatePermissions(Request $request): Response\n{\n    $this-\u003euserHasPermission(PermissionType::GROUP_EDIT);     // only requires GROUP_EDIT \u2014 not SuperAdmin, no per-right check\n    // ... CSRF verified ...\n    $groupId = (int) Filter::filterVar($request-\u003erequest-\u003eget(\u0027group_id\u0027), FILTER_VALIDATE_INT);\n    $groupPermissions = $request-\u003erequest-\u003eall()[\u0027group_rights\u0027];   // attacker-controlled list of right IDs\n\n    $refuseResult = $this-\u003euser-\u003eperm-\u003erefuseAllGroupRights($groupId);\n    if ($refuseResult) {\n        foreach ($groupPermissions as $groupPermission) {\n            $this-\u003euser-\u003eperm-\u003egrantGroupRight($groupId, (int) $groupPermission);   // grants ANY right, unconstrained\n        }\n        ...\n    }\n}\n```\n\nEach `group_rights[]` entry is granted to the group verbatim; there is no verification that the acting administrator holds that right.\n\n**The fixed sibling \u2014 `updateUserRights` DOES constrain to self-held rights (`Controller/Administration/Api/UserController.php:558-579`):**\n\n```php\n$actingIsSuperAdmin = $this-\u003ecurrentUser-\u003eisSuperAdmin();\n// A non-SuperAdmin may only assign rights they hold themselves. This prevents an\n// administrator with the delegable USER_EDIT right from granting privileges they do not\n// possess (privilege escalation).\nif (!$actingIsSuperAdmin) {\n    $actingUserId = $this-\u003ecurrentUser-\u003egetUserId();\n    foreach ($userRights as $userRight) {\n        if (!$this-\u003ecurrentUser-\u003eperm-\u003ehasPermission($actingUserId, (int) $userRight)) {\n            return $this-\u003ejson([\u0027error\u0027 =\u003e Translation::get(key: \u0027msgNoPermission\u0027)], Response::HTTP_FORBIDDEN);\n        }\n    }\n}\n```\n\nThe identical \"may only assign rights you hold\" loop is present for user rights but **absent** for group rights. The group endpoint\u0027s only gate is `userHasPermission(GROUP_EDIT)` (`Controller/AbstractController.php`/`AbstractAdministrationController.php`), which checks the caller holds `GROUP_EDIT` \u2014 not that they hold each right being granted. This is an authorization **omission**: the enforcer the maintainers already wrote for the analogous mass-assignment of rights is simply not applied on the group path.\n\n**Inheritance step (honest precondition).** `grantGroupRight` grants the right to the *group*; the attacker realizes the escalation by being a member of the elevated group. A `GROUP_EDIT` administrator manages groups (and typically their membership), so they can target a group they already belong to or add themselves \u2014 keeping `AC:L`. If a given deployment separates group-membership management from `GROUP_EDIT`, the attacker is limited to elevating groups they already belong to, which is still the common case for a delegated group admin.\n\n## Reproduction\n\nphpMyFAQ is self-hosted; reproduce on your own test instance. Create a non-SuperAdmin account granted `GROUP_EDIT` (and member of some group `G`), log in as it, and run in the DevTools Console:\n\n```js\n// Run as the delegated (non-SuperAdmin) GROUP_EDIT admin, on the phpMyFAQ admin UI.\n// Grant group G (a group the attacker belongs to) a right the attacker does NOT hold\n// (use a numeric RIGHT_ID for a high-value permission the account lacks, e.g. user admin).\nconst csrf = document.querySelector(\u0027[name=\"pmf-csrf-token\"], #pmf-csrf-token\u0027)?.value\n  || window.PMF_CSRF_UPDATE_GROUP_PERMISSIONS;  // the update-group-permissions token rendered on the group page\nconst body = new URLSearchParams();\nbody.set(\"pmf-csrf-token\", csrf);\nbody.set(\"group_id\", String(/* G\u0027s group id */ 2));\nbody.append(\"group_rights[]\", String(/* RIGHT_ID the attacker lacks */ 1));\nfetch(\"/admin/group/update/permissions\", { method: \"POST\", credentials: \"include\", body })\n  .then((r) =\u003e r.text())\n  .then((t) =\u003e console.log(t.includes(\"savedsuc\") ? \"GRANTED (200)\" : t.slice(0, 200)));\n```\n\nExpected result: the response reports success (`ad_msg_savedsuc_*`), i.e. the right was granted to group G even though the acting admin does not hold it. Confirm with `SELECT * FROM faqgroup_right WHERE group_id=2` (or the app\u0027s group-rights view) that the new `right_id` is present, then verify the attacker (a member of G) now exercises the inherited right. (Against `updateUserRights` the same attempt to assign an unheld right returns `403 msgNoPermission`, demonstrating the missing constraint is specific to the group path.)\n\n### End-to-end (source) verification\n\nAuthorization-omission finding; the gap is open at HEAD and reaches the privilege-grant sink with no intervening per-right check:\n\n- **Endpoint reachable by a delegated non-SuperAdmin:** `updatePermissions` gate is `userHasPermission(PermissionType::GROUP_EDIT)` (`:311`) \u2014 confirmed it does not require SuperAdmin nor check the granted rights.\n- **Attacker controls the granted rights:** `group_rights[]` from the request body, granted in the loop at `:329`.\n- **Missing control:** the self-rights loop present in `updateUserRights` (`UserController.php:563-571`) has no counterpart in `updatePermissions` \u2014 verified by reading both handlers at HEAD.\n- **Sink:** `MediumPermission::grantGroupRight` -\u003e `INSERT INTO faqgroup_right` (Permission repository), persisting the unheld right to the group; members of the group inherit it.\n\n## Suggested Fix\n\nApply the same self-rights constraint `updateUserRights` already has, before granting:\n\n```php\n$actingIsSuperAdmin = $this-\u003ecurrentUser-\u003eisSuperAdmin();\nif (!$actingIsSuperAdmin) {\n    $actingUserId = $this-\u003ecurrentUser-\u003egetUserId();\n    foreach ($groupPermissions as $groupPermission) {\n        if (!$this-\u003ecurrentUser-\u003eperm-\u003ehasPermission($actingUserId, (int) $groupPermission)) {\n            throw new UnauthorizedHttpException(\u0027Cannot grant a right you do not hold\u0027);\n        }\n    }\n}\n```\n\nMore robustly, factor the \"you may only assign rights you hold\" rule into the permission layer (`grantGroupRight` / `grantUserRight`) so both the user-rights and group-rights paths enforce it uniformly, and add a regression test mirroring `testUpdateRightsNonSuperAdminCannotGrantRightTheyDoNotHold` for the group endpoint. (See also the related sibling gaps in the same admin-API authorization series: `UserController::addUser` missing the acting-SuperAdmin guard, and the `user/data` / `user/permissions` target-authorization on read.)\n\n## Disclosure Timeline\n\n- 2026-05-30: Discovered while auditing the completeness of the GHSA-xvp4 / GHSA-985r / GHSA-8c6h admin-API authorization-hardening series at `main` HEAD `04db2b999d8d`. The self-rights constraint added to `updateUserRights` was confirmed absent on the `GroupController::updatePermissions` sibling by reading both handlers + the permission gate + the `grantGroupRight` sink.\n- 2026-05-30: Drafted for submission via GitHub Security Advisory.\n\n## References\n\n- Hardening series this incompletely fixes: GHSA-xvp4-phqj-cjr3, GHSA-985r-q3qp-299h (\"incomplete fix for GHSA-xvp4\"), GHSA-8c6h-7g6x-m5x4 (\"incomplete fix for CVE-2026-24421\").\n- Affected source: `phpmyfaq/src/phpMyFAQ/Controller/Administration/GroupController.php:309-349` (`updatePermissions`, gate `userHasPermission(GROUP_EDIT)` at `:311`, sink `grantGroupRight` at `:329`); fixed sibling `Controller/Administration/Api/UserController.php:534-589` (`updateUserRights`, self-rights loop at `:563-566`); `Controller/AbstractController.php:326-336` (`userHasPermission`, the only gate \u2014 `GROUP_EDIT` action permission).\n- Companion advisory (same audit, same series): `user/add` missing acting-SuperAdmin guard -\u003e delegated admin creates SuperAdmin (8.8 High).",
  "id": "GHSA-pg62-f8g4-4wqh",
  "modified": "2026-08-25T17:32:07Z",
  "published": "2026-08-25T17:32:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-pg62-f8g4-4wqh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/commit/de5016607dd606ef161cccd10fa5deec303c834e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thorsten/phpMyFAQ"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "phpMyFAQ privilege escalation: GroupController::updatePermissions lets a GROUP_EDIT admin grant rights they do not hold"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted