CVE-2026-111898 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ 4.2.0-alpha before 4.2.0-beta contains an authentication bypass vulnerability that allows Keycloak users to take over local accounts by matching preferred_username or email. Attackers controlling a Keycloak identity with a colliding username or unverified email can log in through /auth/keycloak/authorize to bind their subject and gain superadmin privileges.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The identified vulnerability in phpMyFAQ versions prior to 4.2.0-beta represents a critical authentication bypass flaw rooted in the integration logic between the application's local user database and external OpenID Connect providers, specifically Keycloak. This security defect allows an attacker who controls a valid identity within the Keycloak provider to hijack existing local accounts by exploiting how the system maps external identities to internal users. The core technical failure lies in the insufficient validation of unique identifiers during the account linking process. When a user authenticates via the /auth/keycloak/authorize endpoint, phpMyFAQ attempts to associate the incoming identity with an existing local account based on specific attributes provided by the Identity Provider.
The mechanism of exploitation relies on the matching criteria used for this association. The system incorrectly prioritizes or accepts matches based on the preferred_username attribute or the email address field without enforcing strict uniqueness constraints or verifying ownership of these identifiers against the local database records. If an attacker registers a Keycloak account with a username that exactly matches the preferred_username of an existing phpMyFAQ user, or if they provide an unverified email address that corresponds to a registered local account, the application will automatically bind the external session to that internal identity. This process occurs without requiring additional proof of ownership for the local account credentials, effectively allowing the attacker to assume the role and permissions associated with the targeted local profile.
The operational impact of this vulnerability is severe, particularly in environments where phpMyFAQ serves as a knowledge base or documentation portal with varying levels of user privilege. By successfully exploiting this flaw, an adversary can gain unauthorized access to any account that shares the matching identifier. In many configurations, especially those involving administrative functions or sensitive data management, there may be local accounts designated with superadmin privileges. Consequently, an attacker controlling a colliding Keycloak identity can escalate their session to achieve full administrative control over the phpMyFAQ instance. This level of access permits the modification of content, extraction of confidential information, and potentially further compromise of the underlying server infrastructure through installed plugins or system-level interactions available to administrators.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as well as CWE-640, Weak Password Recovery Mechanisms for Forgotten Passwords if email-based recovery is involved in the linking process. From a tactical perspective, it relates to MITRE ATT&CK technique T1078, Valid Accounts, where adversaries use legitimate credentials obtained through various means to maintain access and escalate privileges within an organization's network. The flaw highlights the risks associated with loosely coupled identity federation implementations that do not rigorously validate the uniqueness of user attributes before establishing trust between external identities and local accounts.
To mitigate this vulnerability, organizations running phpMyFAQ versions prior to 4.2.0-beta must upgrade immediately to version 4.2.0-beta or later, where the account linking logic has been corrected to prevent such collisions. In addition to upgrading, administrators should review their Keycloak configuration and ensure that email addresses are strictly verified before being exposed in identity tokens if possible. Implementing strict unique constraints on both preferred_username and email fields within phpMyFAQ can also help prevent accidental or malicious overlaps. Furthermore, enabling multi-factor authentication for all administrative accounts adds a layer of defense-in-depth, ensuring that even if an account is compromised via this method, the attacker cannot easily maintain persistent access without additional verification factors. Regular audits of user identities and their associated external providers are recommended to detect any unauthorized associations early in the lifecycle of the application deployment.