Phpmyfaq < 4.1.3 — CraftedSignal Threat Feed

phpMyFAQ Authentication Bypass Allows Account Takeover

hello@craftedsignal.io — Wed, 20 May 2026 15:50:07 +0000

A critical authentication bypass vulnerability exists in phpMyFAQ versions prior to 4.1.3. This flaw allows an unauthenticated attacker to reset the password of any user account, including those with SuperAdmin privileges. The vulnerability stems from the lack of proper password reset token verification, rate limiting, and email confirmation in the /api/user/password/update endpoint. By crafting a simple PUT request containing a valid username and associated email address, an attacker can trigger the system to generate a new plaintext password and transmit it to the user’s email address, effectively granting them complete control over the targeted account. This poses a significant risk to organizations using phpMyFAQ for knowledge management and support purposes.

Attack Chain

The attacker identifies a target phpMyFAQ instance.
The attacker sends a PUT request to /phpmyfaq/api/user/password/update with a valid username and incorrect email address to determine if the username exists (username enumeration).
If the response indicates the username exists, the attacker sends another PUT request to /phpmyfaq/api/user/password/update with the valid username and associated email address in the JSON body.
The phpMyFAQ application, lacking proper authentication, processes the request without requiring any token verification, rate limiting, or email confirmation.
The application generates a new plaintext password for the specified user account.
The application sends the new plaintext password to the user’s email address.
The attacker intercepts the email containing the new password.
The attacker uses the new password to log in to the phpMyFAQ application and take complete control of the account.

Impact

Successful exploitation of this vulnerability allows an attacker to gain full administrative access to a phpMyFAQ installation. This includes the ability to access and modify sensitive information, such as user data and FAQ content. An attacker can also lock out legitimate users, disrupt service availability, and potentially use the compromised system as a platform for further malicious activities. All phpMyFAQ administrators and end-users are potentially impacted, especially those using default installations. The attack has very low complexity, requiring no special knowledge beyond identifying a valid username and associated email address.

Recommendation

Upgrade phpMyFAQ to version 4.1.3 or later to patch the vulnerability as detailed in GHSA-w9xh-5f39-vq89.
Deploy the Sigma rule Detect phpMyFAQ Password Reset Exploit to identify potential exploitation attempts in web server logs.
Implement rate limiting on the /api/user/password/update endpoint to prevent username/email enumeration attacks.

phpMyFAQ Unauthenticated Password Reset Vulnerability

hello@craftedsignal.io — Wed, 20 May 2026 15:47:42 +0000

phpMyFAQ versions prior to 4.1.3 are vulnerable to an unauthenticated password reset vulnerability. The vulnerability resides in the password reset API, which lacks proper authentication and authorization checks. An attacker can exploit this by sending a crafted request to the /api/index.php/user/password/update endpoint with a valid username and email combination. Upon receiving this request, the application immediately generates a new password, updates the user’s account, and sends the new password to the user’s email address. This bypasses the intended password reset flow, allowing attackers to forcibly change passwords without any out-of-band confirmation or token validation. This issue was confirmed in a local Docker deployment.

Attack Chain

The attacker identifies a potential target username and email address.
The attacker crafts a PUT request to /api/index.php/user/password/update with the target’s username and email in the JSON body.
The phpMyFAQ application receives the request at phpmyfaq/src/phpMyFAQ/Controller/Frontend/Api/UnauthorizedUserController.php.
The application checks if the provided username and email combination exists.
If the username and email are valid, the application generates a new password.
The application updates the user’s password in the database with the newly generated password.
The application sends the new password to the user’s email address.
The attacker has now forced a password reset, effectively locking the user out of their account using the original password.

Impact

The unauthenticated password reset vulnerability in phpMyFAQ allows attackers to enumerate valid usernames and email addresses. More critically, it enables attackers to forcibly reset user passwords, leading to account disruption and potential denial of service. An attacker knowing a valid username/email pair can trigger an immediate password change without any confirmation, invalidating the old password. While the attacker might not gain immediate access to the account if they lack access to the email, the forced password reset disrupts the victim’s access and could lead to further exploitation if the attacker can intercept the new password.

Recommendation

Apply the provided patch or upgrade to phpMyFAQ version 4.1.3 or later to remediate the vulnerability.
Deploy the Sigma rule Detect phpMyFAQ Password Reset Attempt to monitor for suspicious PUT requests to the password update endpoint.
Implement rate limiting on the /api/index.php/user/password/update endpoint to mitigate brute-force attempts to enumerate valid username/email pairs.
Change the password recovery flow to a token-based design as outlined in the source document, generating reset tokens and validating those tokens before resetting the password.

phpMyFAQ IDOR Allows Admin Account Takeover

hello@craftedsignal.io — Wed, 20 May 2026 15:47:28 +0000

An Insecure Direct Object Reference (IDOR) vulnerability exists in phpMyFAQ versions prior to 4.1.3. The vulnerability is located in the Admin API within the overwritePassword() method, which lacks proper authorization checks. Any authenticated administrator, even those with low privileges (USER_EDIT permission), can change the password of any user account, including the SuperAdmin account (userId=1). By manipulating the userId parameter in a PUT request to /admin/api/user/overwrite-password, an attacker can escalate their privileges to full SuperAdmin control. This poses a significant risk to organizations with multiple admin users and environments requiring privilege separation or multi-tenancy.

Attack Chain

The attacker gains access to a low-privilege admin account, either through legitimate means or by exploiting a separate vulnerability.
The attacker identifies the overwritePassword() endpoint /admin/api/user/overwrite-password and its lack of authorization checks.
The attacker requests a CSRF token from an admin page using curl and grep.
The attacker crafts a PUT request to the /admin/api/user/overwrite-password endpoint. The request body includes a JSON payload with the target userId set to ‘1’ (SuperAdmin), a valid CSRF token, and the desired new password for the SuperAdmin account.
The phpMyFAQ application receives the PUT request and, due to the IDOR vulnerability, does not validate whether the requesting admin has permission to modify the target user’s password.
The overwritePassword() method changes the SuperAdmin’s password to the attacker-supplied password.
The attacker logs in as the SuperAdmin using the newly set password.
The attacker now has full control of the phpMyFAQ application and can perform any administrative task.

Impact

Successful exploitation of this IDOR vulnerability allows an attacker to gain complete control of the phpMyFAQ application. This can lead to data breaches, defacement of the FAQ content, and unauthorized modification of system configurations. Organizations with multiple admin users, where not all should have SuperAdmin access, are particularly vulnerable. In multi-tenant environments, this vulnerability could allow an attacker to compromise all tenants managed by the phpMyFAQ instance.

Recommendation

Upgrade phpMyFAQ to version 4.1.3 or later to patch the IDOR vulnerability.
Implement the Sigma rule Detect phpMyFAQ Admin Password Overwrite to detect potential exploitation attempts (see below).
Review and restrict admin privileges based on the principle of least privilege to limit the impact of potential account compromises.
Enable multi-factor authentication for all admin accounts to further mitigate the risk of unauthorized access.