CVE-2026-111895 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ 3.2.0 before 4.0.0 and 4.0.2 before 4.2.0-beta contains an authentication bypass in its Microsoft Entra ID login flow, which links users by the mutable preferred_username claim and whose AuthEntraId::create() ignores the duplicate-login exception while continuing with the existing local account. Attackers controlling an Entra identity in the configured tenant with a matching preferred_username can take over that local account, including super-admin accounts.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in phpMyFAQ versions 3.2.0 through 4.0.0 and 4.0.2 through 4.2.0-beta represents a critical authentication bypass within the Microsoft Entra ID integration module. This flaw stems from an insecure implementation of user account linking logic during the Single Sign-On process. Specifically, the system relies on the preferred_username claim provided by the identity provider to associate external federated identities with existing local accounts in the phpMyFAQ database. The core technical deficiency lies in how the AuthEntraId::create() method handles duplicate login exceptions. When a user attempts to log in via Microsoft Entra ID and an account already exists with that identifier, the system is designed to throw an exception indicating a conflict. However, instead of rejecting this ambiguous state or requiring re-authentication, the code catches this exception and proceeds to link the incoming federated session directly to the pre-existing local account without verifying ownership or prompting for additional credentials.
This logic error creates a severe identity confusion scenario that allows attackers to hijack existing user accounts. If an attacker controls a Microsoft Entra ID tenant configured within phpMyFAQ, they can create a new identity with a preferred_username value that matches any target local account in the system. Upon attempting to log in using this controlled external identity, the authentication flow will encounter the duplicate login exception but will silently ignore it and establish a session for the targeted local user. This effectively bypasses the need for the victim's password or multi-factor authentication methods associated with their local credentials. The impact is particularly severe because phpMyFAQ supports super-admin accounts which possess unrestricted access to all system configurations, database structures, and content management features. An attacker gaining control of a super-admin account through this method can execute arbitrary code, exfiltrate sensitive data, modify application settings, or install persistent backdoors within the web application infrastructure.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to adequately verify the identity of users attempting to access resources via federated credentials. It also relates closely to CWE-640 Weak Password Recovery Mechanisms for Forgotten Passwords in terms of account linking risks, though more accurately it falls under CWE-598 Use of GET Request Method With Sensitive Query Strings if query parameters were involved, but here the primary issue is Account Takeover via Identity Provider manipulation. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts and specifically T1078.004 Cloud Accounts, where adversaries leverage legitimate cloud identities to gain unauthorized access. The attack vector involves Initial Access through valid credentials obtained or created by the attacker in a trusted identity provider environment, leading directly to Privilege Escalation if an administrative account is targeted.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective solution is to upgrade phpMyFAQ to version 4.2.0-beta or later where this specific logic flaw has been addressed by the developers. For organizations unable to immediately patch, a temporary workaround involves disabling Microsoft Entra ID authentication entirely if it is not strictly required for business operations. Alternatively, administrators should implement strict monitoring and logging around login events associated with federated identities to detect unusual patterns such as rapid account linking attempts or logins from unexpected geographic locations. It is also advisable to review the configuration of trusted identity providers to ensure that only authorized tenants can authenticate against the phpMyFAQ instance. Future implementations of SSO integrations should avoid relying solely on mutable claims like preferred_username for automatic account linking without additional verification steps, such as requiring manual confirmation or re-authentication when a conflict arises between existing local accounts and incoming federated identities.