GHSA-985R-Q3QP-299H: Incomplete Fix in phpMyFAQ Admin API Enables Privilege Escalation and Account Takeover

The phpMyFAQ platform manages user accounts and privileges through RESTful endpoints under /admin/api/user/. When processing administrative requests, the application relies on an authorization hierarchy to distinguish between general administrators and SuperAdmin accounts. A previous security advisory (GHSA-xvp4-phqj-cjr3) identified that standard administrative users could reset any password via the overwritePassword endpoint, bypassing authorization controls.

While the vendor successfully resolved the direct password modification vector in overwritePassword, the architectural pattern governing other endpoints in the same controller remained unchanged. The endpoints editUser and updateUserRights remain exposed to an Insecure Direct Object Reference (IDOR) flaw, classified under CWE-639. This vulnerability represents a regression by omission, leaving critical profile-management routes without proper access restrictions.

An attacker with active credentials for a low-privilege administrative role can exploit these endpoints. The administrative panel only verifies that the actor has permission to load the administration dashboard. It fails to restrict the scope of modifications, allowing the modification of parameters belonging to higher-privileged users.

The primary defect lies in src/phpMyFAQ/Controller/Administration/Api/UserController.php. Both the editUser() and updateUserRights() methods validate the initiating session's permission status using a global access-control function. This check is represented by $this->userHasUserPermission(), which verifies whether the active user possesses general rights to edit user accounts in the system.

This system lacks granular, object-level checks. Once the global authorization check completes successfully, the application receives a client-controlled variable, userId, from the raw request payload. The system queries this identifier directly in the database and executes modifications without verifying whether the initiating user possesses authority over the target user.

Consequently, the application treats any request matching the general privilege schema as authorized, regardless of the relative privilege level of the targets. A standard administrator can thus submit requests targeting the SuperAdmin account (userId = 1). This allows the modification of critical parameters, such as group permissions and registered email addresses, which compromises the integrity of the privilege boundary.

The unpatched implementation of the editUser endpoint in UserController.php processes incoming JSON data directly without validating the hierarchy of the target account relative to the actor.

// UNPATCHED CODE PATH
public function editUser(Request $request): JsonResponse
{
    // Generic permission check (actor is a basic admin)
    $this->userHasUserPermission();
 
    $data = json_decode($request->getContent());
    $userId = Filter::filterVar($data->userId, FILTER_VALIDATE_INT);
 
    // No validation ensures that a non-SuperAdmin is prohibited from modifying a SuperAdmin
    $user = $this->userService->getUserById($userId);
    $user->setLogin($data->login);
    $user->setEmail($data->email);
    $user->setDisplayName($data->displayName);
 
    $this->userService->updateUser($user);
    return $this->json(['status' => 'success']);
}

To remediate this structural flaw, the application must enforce an explicit validation check. It must verify that a standard administrator cannot execute modifications targeting a SuperAdmin account.

// MITIGATED CODE PATH
public function editUser(Request $request): JsonResponse
{
    // Step 1: Execute general administrative authorization check
    $this->userHasUserPermission();
 
    $currentUser = CurrentUser::getCurrentUser($this->configuration);
    $data = json_decode($request->getContent());
    $userId = Filter::filterVar($data->userId, FILTER_VALIDATE_INT);
 
    // Step 2: Retrieve target account details
    $targetUser = $this->userService->getUserById($userId);
 
    // Step 3: Reject modification if the target is a SuperAdmin and the actor is not
    if ($targetUser->isSuperAdmin() && !$currentUser->isSuperAdmin()) {
        return $this->json(
            ['error' => 'Unauthorized modification of SuperAdmin records'],
            Response::HTTP_FORBIDDEN
        );
    }
 
    // Proceed with state updates only if validation criteria are met
    $targetUser->setLogin($data->login);
    $targetUser->setEmail($data->email);
    $this->userService->updateUser($targetUser);
 
    return $this->json(['status' => 'success']);
}

An attacker with low-privilege administrative access can achieve complete system takeover via two distinct vectors. These abuse the functional omissions in editUser and updateUserRights respectively.

In Vector A, the attacker targets the editUser endpoint to modify the SuperAdmin's email address. The attacker constructs a PUT request containing the targeted SuperAdmin ID alongside an email address controlled by the attacker.

PUT /admin/api/user/edit HTTP/1.1
Host: target-phpmyfaq.local
Content-Type: application/json
Cookie: phpMyFAQ=session_cookie_here
X-CSRF-Token: valid_csrf_token_here
 
{
  "userId": 1,
  "login": "admin",
  "email": "attacker@controlled-domain.com",
  "displayName": "Administrator"
}

Because of the missing vertical authorization checks, the backend processes the request and updates the database record. The attacker then uses the application's native "Forgot Password" feature. This generates a recovery token and delivers it to the attacker's server, completing the compromise of the primary administrator account.

In Vector B, the attacker targets the updateUserRights endpoint. This allows them to alter group associations or direct access control list (ACL) mapping. The attacker sends a request specifying their own userId and assigns high-privilege roles or permissions.

This vulnerability completely undermines the tenant and administrative privilege isolation within the phpMyFAQ application. By escalating privileges to SuperAdmin status, an attacker gains unrestricted read, write, and execute permissions across the system. This allows them to view all database tables, modify internal portal content, and alter system configurations.

In a standard system setup, an attacker with SuperAdmin access can also execute arbitrary PHP code on the underlying web server. This is achieved by utilizing the system's administrative file-upload or template-modification utilities. Consequently, the IDOR vulnerability in the API leads directly to remote code execution (RCE).

This vulnerability is analyzed using the CVSS v3.1 vector string below. The scope remains unchanged because the compromise occurs within the same application logical context, though the impact on integrity, confidentiality, and availability is absolute.

To remediate this vulnerability, administrators must update the phpMyFAQ installation to a version that includes the completed authorization patch. Standard configuration changes are insufficient because the vulnerability resides directly in the API controller logic.

Organizations that cannot apply the patch immediately should restrict access to the administration directory. This can be done by enforcing network-level restrictions, such as IP address allowlists or Virtual Private Network (VPN) requirements. Additionally, security teams can implement Web Application Firewall (WAF) rules to inspect and block incoming administrative PUT requests to /admin/api/user/* if the payload targets critical accounts.

To ensure defense-in-depth, configure the database with the principle of least privilege. In addition, enable detailed administrative logging to capture all requests destined for user modification endpoints.