Listen to this Post
The vulnerability exists in the password reset API endpoint at /api/user/password/update, which can be triggered without any authentication. The code resides in UnauthorizedUserController.php. The route is defined with the `
` attribute and allows `PUT` methods without any authentication middleware. When a request reaches the `updatePassword` method, the application retrieves the username and email from the JSON body. It then checks if a user exists with the provided username and if the provided email matches the stored email for that user. If both conditions are true, the application proceeds to generate a new password using `$user->createPassword()` and immediately changes the user's password with <code>$user->changePassword($newPassword)</code>. Only after the password has been changed does the application send an email containing the new plaintext password. If the username and email do not match, the endpoint returns a `409 Conflict` error, indicating a mismatch. There is no token generation, no confirmation link, no rate limiting, and no requirement for the caller to prove control of the email inbox before the password is replaced. This means the endpoint functions as an unauthenticated password change trigger rather than a proper "forgot password" flow. An attacker can use this to confirm whether a username and email pair is valid by observing the difference between a `200 OK` and a `409 Conflict` response. Furthermore, by sending a valid pair, the attacker can force a password reset for the target account, immediately invalidating the victim's existing password and potentially causing a denial of service. If the attacker also has access to the victim's email inbox, they can intercept the new password and achieve a full account takeover. The vulnerability affects all user accounts, including SuperAdmin accounts. <h2 style="color: blue;">DailyCVE Form</h2> [bash] Platform: phpMyFAQ Version: 4.0.x Vulnerability : Weak Password Recovery Severity: High date: 2026-05-20 Prediction: Patch already available
What Undercode Say:
Check if user exists via response difference
curl -X PUT -H "Content-Type: application/json" -d '{"username":"admin","email":"[email protected]"}' http://target/phpmyfaq/api/user/password/update
Expected output for non-matching email: {"error":"The email doesn't exist..."}
Perform unauthenticated password reset for a valid user
curl -X PUT -H "Content-Type: application/json" -d '{"username":"admin","email":"[email protected]"}' http://target/phpmyfaq/api/user/password/update
Expected output: {"success":"Email has been sent."}
Verify the user's password hash was overwritten
(Old hash in `faquserlogin` table is replaced)
Exploit:
The exploit is trivial. An attacker only needs to know a valid username and its associated email address. A single PUT request to the `/api/user/password/update` endpoint with a JSON payload containing these two fields will force a password reset. No authentication, session, or CSRF token is required. The attack can be automated and scaled, as the endpoint lacks rate limiting.
Protection from this CVE:
- Immediate Upgrade: Apply the security update from the vendor, which is already available.
- Implement Token-Based Reset: The password reset flow must be redesigned to use a time-limited, single-use cryptographic token sent to the user’s email. The password should only be changed after the token is submitted.
- Unify Error Responses: The API should return the same generic error message (e.g., a `200 OK` with a generic message) for both valid and invalid username/email pairs to prevent account enumeration.
- Apply Rate Limiting: Implement strict rate limiting on the password reset endpoint to mitigate brute-force enumeration and automated attacks.
Impact:
- Account Takeover: If the attacker has access to the victim’s email inbox (e.g., via a separate vulnerability or compromised account), they can intercept the new password and fully compromise the account.
- Denial of Service (DoS): An attacker can repeatedly force password resets for a targeted account, rendering the victim unable to log in with their known credentials. This causes significant disruption.
- Account Enumeration: The difference in HTTP response codes (
200 OKvs409 Conflict) allows an attacker to build a list of valid user accounts and their associated email addresses. - Privilege Escalation: The vulnerability can be used against any user, including SuperAdmin accounts, potentially granting full administrative access to the entire FAQ system.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
