CVE-2026-111885 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ from 4.2.0-alpha before 4.2.0-beta contains a missing authorization vulnerability in GroupController::deleteGroup() that omits privilege-level checks on target groups. Authenticated non-SuperAdmin administrators holding GROUP_DELETE can send a crafted groupId to /admin/api/group/delete to permanently destroy higher-privileged groups and strip members' inherited rights.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The identified vulnerability resides within the phpMyFAQ content management system, specifically affecting versions prior to 4.2.0-beta in the GroupController component. This security flaw is classified as a Broken Access Control issue, aligning with CWE-862 (Missing Authorization) and corresponding to MITRE ATT&CK technique T1078 (Valid Accounts). The core technical defect lies in the deleteGroup method of the API endpoint /admin/api/group/delete. While the system correctly verifies that an authenticated user possesses the GROUP_DELETE permission, it fails to validate whether the requesting administrator has sufficient privilege levels relative to the target group being deleted. This oversight allows any administrator with basic deletion rights to bypass hierarchical security constraints and execute destructive actions against groups possessing higher privileges than their own role warrants.
From a technical perspective, the vulnerability exploits the lack of vertical access control checks within the backend logic. When an authenticated user initiates a request to delete a group by providing a specific groupId parameter, the application processes this command without verifying if the requester's administrative tier permits interaction with that specific level of entity. Consequently, a standard administrator can target and permanently destroy groups designated for SuperAdmins or other high-privilege roles. This mechanism bypasses intended security boundaries because the authorization logic relies solely on the presence of a generic delete permission rather than evaluating the relationship between the actor's role and the resource's sensitivity level.
The operational impact of this vulnerability is severe, leading to potential complete compromise of administrative controls within the phpMyFAQ instance. By deleting higher-privileged groups, an attacker can effectively strip members of their inherited rights, causing significant disruption to organizational workflows and data access policies. Furthermore, the destruction of these groups may lead to a denial of service for legitimate users who rely on those group structures for authentication or authorization purposes. In more advanced attack scenarios, this capability could facilitate privilege escalation if the deletion process triggers cascading effects that weaken other security controls or expose sensitive configuration data during the cleanup phase.
Mitigation strategies must focus on implementing robust vertical access control mechanisms within the application code. Developers should ensure that every administrative action involving resource modification includes a check verifying that the requesting user's role level is equal to or greater than the privilege level of the target entity. Additionally, enforcing principle of least privilege by restricting GROUP_DELETE permissions only to SuperAdmins would eliminate this attack vector entirely until a patch is applied. Organizations running affected versions should immediately upgrade to version 4.2.0-beta or later where these authorization checks have been corrected. In the interim, network-level controls such as Web Application Firewalls can be configured to monitor and restrict access to the /admin/api/group/delete endpoint based on user role headers if available, although this is a compensatory measure rather than a fix for the underlying code defect.