CVE-2026-85590 in phpMyFAQ
Summary
by MITRE • 09/04/2026
phpMyFAQ before 4.1.8 contains an authentication bypass vulnerability in its two-factor authentication (TOTP) disable functionality. The removeTwofactorConfig() handler (reachable via POST /api/user/remove-twofactor) verifies only that the user is logged in and that a valid CSRF token is supplied, then disables TOTP without requiring password re-entry or a current TOTP code. The same downgrade is also reachable inline via PUT /api/user/data/update, which accepts a plain twofactor_enabled form field under the same session+CSRF-only guard. An attacker who has hijacked a user's session can silently strip two-factor protection from any account, including administrator accounts, after which password-only authentication succeeds.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in phpMyFAQ versions prior to 4.1.8 represents a critical flaw within the application’s multi-factor authentication implementation, specifically targeting the mechanism used to disable Time-based One-Time Password (TOTP) protection. This issue stems from an insecure direct object reference combined with insufficient verification of user intent during sensitive configuration changes. The core technical failure lies in the design of the removeTwofactorConfig() handler and the PUT /api/user/data/update endpoint, both of which are responsible for modifying critical security settings related to account authentication methods. These endpoints operate under a flawed trust model that assumes possession of a valid session cookie and a correct Cross-Site Request Forgery (CSRF) token is sufficient proof of legitimate user action. This assumption ignores the fundamental principle that disabling two-factor authentication constitutes a high-risk operation requiring explicit, out-of-band confirmation to prevent unauthorized account takeover in scenarios where an attacker has already gained partial access through session hijacking or other means.
From a technical perspective, the vulnerability allows for the silent removal of TOTP requirements without demanding re-authentication via password entry or submission of a current valid TOTP code. When an authenticated user initiates a request to either POST /api/user/remove-twofactor or PUT /api/user/data/update with the twofactor_enabled field set to disable, the server validates only that the requester is logged in and presents a valid CSRF token. It does not verify whether the current password matches the account’s stored hash nor does it require a fresh TOTP code to confirm active possession of the second factor. This design oversight creates a significant gap in security controls, as it permits an attacker who has obtained or hijacked a user's session identifier to bypass the secondary layer of authentication entirely. The absence of step-up authentication for such sensitive configuration changes means that once initial access is compromised, the defender’s primary defense mechanism can be neutralized without triggering additional verification steps that would typically alert the legitimate user or block unauthorized modifications.
The operational impact of this vulnerability is severe, particularly in environments where phpMyFAQ serves as a knowledge base with administrative capabilities accessible to multiple users. An attacker who successfully hijacks a session for any account, including those with elevated privileges such as administrators, can strip away two-factor protection and subsequently authenticate using only the known or cracked password associated with that account. This effectively reduces the security posture of the application from multi-factor authentication back to single-factor authentication, significantly lowering the barrier for full account compromise. In administrative contexts, this could lead to unauthorized modification of site settings, injection of malicious content into knowledge articles, exfiltration of sensitive data stored within the FAQ system, or further lateral movement if the compromised admin credentials are reused elsewhere in an organization’s infrastructure. The ability to silently disable TOTP also undermines audit trails and security monitoring efforts, as the change may go unnoticed until after a breach has occurred.
This vulnerability aligns with several established industry standards for classifying software weaknesses. It is primarily categorized under CWE-287: Improper Authentication, specifically reflecting failures in verifying identity during critical state changes. Additionally, it relates to CWE-352: Cross-Site Request Forgery (CSRF), as the reliance on CSRF tokens without additional confirmation mechanisms leaves the application vulnerable to attacks where an attacker leverages a victim’s active session to perform unauthorized actions. From a tactical perspective, this flaw supports techniques described in MITRE ATT&CK such as T1078: Valid Accounts and T1534: Internal Spearphishing if combined with social engineering to obtain initial access, followed by privilege escalation or persistence establishment through the removal of security controls. The specific action of disabling MFA falls under the broader category of Defense Evasion techniques where an adversary removes tools or configurations that could detect their presence or hinder further exploitation.
To mitigate this vulnerability and prevent similar issues in future development cycles, it is imperative to implement step-up authentication for any operation that modifies critical security settings. Disabling two-factor authentication must require re-entry of the user’s current password and potentially a valid TOTP code from an already enrolled device to confirm active possession of both factors before allowing the change. This ensures that even if a session token is compromised, the attacker cannot easily remove secondary protections without also possessing the victim's credentials or physical access to their authenticator app. Furthermore, developers should enforce strict input validation and context-specific CSRF protection strategies that account for the sensitivity level of each endpoint. Implementing explicit confirmation dialogs on the client side can provide an additional layer of defense by alerting users when sensitive changes are being made, although this must not be relied upon as a sole security control since it can be bypassed via automated requests. Regular security audits and penetration testing focusing on authentication flows will help identify such logical flaws before they can be exploited in production environments.