CVE-2026-85591 in phpMyFAQ
Summary
by MITRE • 09/04/2026
phpMyFAQ versions before 4.1.8 contain an authentication bypass vulnerability in the user control panel API endpoint that allows authenticated attackers to change account passwords without verifying the current password. Attackers with session access can submit a PUT request to the user data update endpoint with only a CSRF token to silently change any user's password, including administrators, causing irreversible account takeover and victim lockout.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in phpMyFAQ versions prior to 4.1.8 represents a critical authentication bypass flaw within the application’s user control panel API endpoint. This security defect specifically affects the mechanism used for updating user profile data, allowing attackers who have obtained valid session credentials or tokens to manipulate account settings without proper verification of existing credentials. The core technical issue lies in the server-side validation logic associated with the PUT request handler for user data updates. When a client submits a modification request to change an account password, the application fails to require the submission of the current password as part of the authentication challenge. Instead, the system relies solely on the presence of a valid CSRF token and session cookie to authorize the operation. This design oversight effectively treats any authenticated state as sufficient proof of identity for sensitive configuration changes, ignoring the principle that changing security-critical attributes like passwords requires re-authentication or explicit verification of existing secrets.
From an operational perspective, this vulnerability enables severe account takeover scenarios with minimal effort from an attacker. Since the attack vector involves submitting a PUT request to the user data update endpoint using only a CSRF token and session access, it is highly exploitable in environments where cross-site scripting vulnerabilities exist or where session tokens can be intercepted through man-in-the-middle attacks if HTTPS is not strictly enforced. An adversary who gains access to any valid user’s session, including those with administrative privileges, can silently change the password associated with that account. This action results in immediate and irreversible lockout for the legitimate owner of the account, as they are no longer able to authenticate using their original credentials. The impact is particularly acute because it does not require privilege escalation beyond what was already possessed; even a low-privileged user could potentially target an administrator’s session if that session becomes compromised through other means, leading to full system compromise due to phpMyFAQ's role in managing knowledge base content and often integrating with broader organizational workflows.
This vulnerability aligns closely with CWE-287 Improper Authentication, as the application fails to adequately verify identity before performing a sensitive action. Furthermore, it relates to CWE-613 Insufficient Session Expiration, given that the reliance on session tokens without re-authentication for password changes exacerbates the risk associated with stolen or hijacked sessions. In terms of MITRE ATT&CK mapping, this behavior facilitates Account Manipulation techniques where an adversary modifies account credentials to maintain persistent access while denying legitimate users entry. The lack of current password verification also touches upon CWE-352 Cross-Site Request Forgery if the CSRF protection is deemed insufficient against sophisticated attacks that can mimic valid user actions within the context of a trusted session, although the primary failure here is the absence of secondary authentication factors for high-risk operations.
To mitigate this vulnerability, immediate updates to phpMyFAQ version 4.1.8 or later are required, as these versions include patches addressing the flawed validation logic in the API endpoint. For organizations unable to patch immediately due to compatibility constraints, implementing a Web Application Firewall rule that monitors and restricts PUT requests to user data endpoints can provide temporary protection by ensuring that only expected parameters are processed. Additionally, enforcing strict session management policies such as short-lived sessions, secure cookie flags including HttpOnly and Secure attributes, and regular rotation of CSRF tokens can reduce the window of opportunity for attackers exploiting stolen credentials. It is also recommended to implement multi-factor authentication across all user accounts, particularly administrative ones, so that even if a password is changed maliciously, the attacker cannot fully utilize the compromised account without the second factor. Regular security audits focusing on API endpoint validation logic and adherence to OWASP guidelines for sensitive data modification should be conducted to prevent similar flaws in future development cycles.