GHSA-9qv9-8xv6-5p35: Unauthenticated Password Reset and Enumeration Flaw in phpMyFAQ

GHSA-9qv9-8xv6-5p35 exposes a fundamental logic flaw in the REST API components of phpMyFAQ, specifically affecting version 4.1.2 and earlier. The application implements an insecure password recovery mechanism that violates standard identity verification workflows.

Secure password reset flows require an out-of-band verification step, typically generating a cryptographic token sent to the user's registered email address. The password is only updated in the database after the user submits this valid, time-bound token back to the server.

In the vulnerable implementation, phpMyFAQ processes the password reset in a single, synchronous step. Upon receiving a request containing a valid username and corresponding email address, the application immediately generates a new password and overwrites the existing credentials in the database before dispatching the notification email.

This behavior introduces two distinct security issues: a Weak Password Recovery Mechanism (CWE-640) and Information Exposure Through Discrepancy (CWE-204). Remote, unauthenticated attackers can leverage these flaws to disrupt access for legitimate users and accurately map registered accounts on the target system.

The vulnerability originates in the UnauthorizedUserController class, which handles public-facing API requests that do not require an active session. The specific function at fault is the updatePassword method, mapped to the PUT /api/index.php/user/password/update endpoint.

When a client submits a PUT request to this endpoint, the application extracts the username and email fields from the JSON payload. The application queries the faquserlogin table to determine if the username exists and subsequently verifies if the provided email matches the stored record for that user.

If both conditions evaluate to true, the application instantiates a password generation routine. The critical error occurs in the immediate execution of the $user->changePassword($newPassword) function. This function persists the newly generated password to the database synchronously, permanently destroying the user's previous credentials.

Only after the database transaction is finalized does the application attempt to send the new password to the user via the $mail->send() method. The failure to defer the database update until the user proves control of the email address constitutes the core logic flaw.

An analysis of the vulnerable source code in phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php demonstrates the immediate credential modification.

#[Route(path: 'user/password/update', name: 'api.private.user.password', methods: ['PUT'])]
public function updatePassword(Request $request): JsonResponse {
    // Extract username and email from JSON body
    $loginExist = $user->getUserByLogin($username);
 
    if ($loginExist && $email === $user->getUserData('email')) {
        $newPassword = $user->createPassword();
        
        // VULNERABILITY: Password changed immediately in the DB
        $user->changePassword($newPassword); 
        
        $mail->send();
        return $this->json(['success' => 'Email has been sent.'], Response::HTTP_OK);
    }
 
    // VULNERABILITY: Observable discrepancy permits enumeration
    return $this->json(['error' => 'Error: Username and email address not found.'], Response::HTTP_CONFLICT);
}

The code block above highlights both the forced reset and the enumeration flaw. The application returns an HTTP 200 OK status for valid inputs and an HTTP 409 Conflict for invalid inputs.

The patch introduced in version 4.1.3 resolves this by overhauling the recovery workflow. Instead of generating a password, the system now generates a temporary validation token, emails the token to the user, and requires a subsequent API call providing the token to authorize the password update. The patch also standardizes the API response to prevent enumeration.

Exploitation requires zero privileges and minimal network access. An attacker interacts directly with the exposed REST API using standard HTTP client tools.

To execute the forced password reset, the attacker constructs a PUT request containing the targeted user's known username and email address. The payload structure requires a basic JSON body.

PUT /api/index.php/user/password/update HTTP/1.1
Host: target-phpmyfaq-instance.local
Content-Type: application/json
 
{
  "username": "admin",
  "email": "admin@example.com"
}

If the targeted user exists, the server returns an HTTP 200 OK response. At this precise moment, the targeted user's active session remains valid, but their stored password is changed. Once their session expires or they attempt to log in from a new device, they will be denied access until they retrieve the system-generated password from their email inbox.

Attackers utilize the observable discrepancies in the HTTP response codes to conduct user enumeration. By iterating through lists of common usernames and company email structures, an attacker automates requests to the endpoint. An HTTP 409 Conflict confirms the user does not exist, while an HTTP 200 OK confirms a valid target, simultaneously locking that user out of their account.

The vulnerability carries a CVSS v3.1 base score of 7.0, reflecting its high impact on system integrity and its fully remote, unauthenticated attack vector. The absence of complex preconditions makes this flaw highly reproducible in default deployments.

The immediate consequence is localized Denial of Service (DoS) through account disruption. Attackers can script continuous requests against targeted administrative accounts, ensuring the database password changes repeatedly. This prevents legitimate administrators from successfully logging in, as the password emailed to them is invalidated by the next automated attack request before it can be used.

The enumeration capability presents significant risks for organizational security posture. Attackers map valid internal identities, facilitating targeted spear-phishing campaigns or brute-force attacks against other enterprise services.

While this vulnerability does not directly expose the new password to the attacker, it severely degrades access controls. If an attacker possesses secondary access to the victim's communication channels, such as a compromised email inbox or the ability to intercept outbound SMTP traffic, this logic flaw escalates immediately to full account takeover.

The primary remediation strategy requires upgrading the phpMyFAQ deployment to version 4.1.3 or later. This version replaces the synchronous password reset with a secure, token-based verification flow and normalizes API responses to mitigate enumeration.

Organizations unable to patch immediately should implement compensating controls at the network perimeter. Web Application Firewalls (WAF) or reverse proxies can be configured to block or rate-limit unauthenticated PUT requests to the /api/index.php/user/password/update endpoint.

Security operations teams should monitor web server access logs and API gateways for suspicious activity patterns. Sequences of HTTP 409 Conflict responses originating from a single IP address, particularly when targeting the password update endpoint, indicate active user enumeration attempts.

Administrators should also audit internal mail server logs. An abnormal spike in password reset notifications originating from the phpMyFAQ application server serves as a high-fidelity indicator that the forced reset vulnerability is being actively exploited.