CVE-2026-111889 in phpMyFAQ
Summary
by MITRE • 10/17/2026
phpMyFAQ from 4.1.0 before 4.1.9 and 4.2.0-alpha before 4.2.0-beta contains a missing authorization vulnerability in the admin dashboard that allows authenticated users without admin rights to view restricted data. Attackers with any activated account can request /admin/index.php/ to read unpublished FAQ questions, admin edit URLs, recent user identities, and site statistics.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/17/2026
The identified security flaw resides within phpMyFAQ versions ranging from 4.1.0 up to but not including 4.1.9, as well as the alpha releases prior to version 4.2.0-beta. This vulnerability is classified as a missing authorization issue, specifically falling under CWE-862 which denotes Missing Authorization. The core of the problem lies in the access control mechanisms governing the administrative dashboard interface. While phpMyFAQ implements role-based access controls intended to restrict sensitive functionalities and data visibility to users with administrator privileges, these checks are insufficiently enforced for certain endpoints within the admin section. Consequently, any user account that is activated on the platform, regardless of its assigned role or permission level, can bypass these restrictions by directly accessing specific administrative URLs.
The technical manifestation of this vulnerability occurs when an authenticated non-administrator user sends a request to the /admin/index.php endpoint. Under normal operational security expectations, such a path should trigger a server-side verification process that confirms the requester holds the necessary admin rights before rendering any content or executing backend logic associated with administration tasks. However, due to the implementation flaw in these specific versions, this verification step is either skipped or incorrectly evaluated for non-admin users. As a result, the application serves administrative data and interface elements to unauthorized parties without raising an access denied error or redirecting them appropriately. This represents a significant breakdown in the principle of least privilege, allowing lower-privileged entities to interact with high-security components of the system.
The operational impact of this vulnerability is substantial as it leads to the exposure of sensitive internal information that should remain confidential within the administrative scope. Attackers possessing any valid user account can exploit this flaw to view unpublished FAQ questions, which may contain draft content intended for future publication or private use. Furthermore, they gain access to admin edit URLs, providing a roadmap of how administrators manage and modify site content, potentially facilitating further targeted attacks against specific entries. The disclosure of recent user identities compromises the privacy of registered members and could be leveraged for social engineering campaigns or credential stuffing attempts if additional data is exposed elsewhere. Additionally, the exposure of site statistics provides attackers with insights into traffic patterns, active periods, and overall system usage, which aids in reconnaissance efforts to identify high-value targets or optimal times for launching more disruptive attacks such as denial-of-service operations.
This vulnerability aligns closely with MITRE ATT&CK technique T1078, Valid Accounts, where adversaries use legitimate credentials to access resources they are not authorized to view. It also relates to T1530, Data from Local System, in the context of data staging and exfiltration preparation, although here it is primarily about unauthorized viewing rather than active theft at this stage. The lack of proper authorization checks on administrative endpoints creates a pathway for information disclosure that undermines the integrity and confidentiality guarantees provided by the application's security model.
To mitigate this vulnerability, administrators must immediately upgrade phpMyFAQ to version 4.1.9 or later, where these access control issues have been addressed in subsequent releases. Until an update can be applied, it is advisable to restrict direct web access to the /admin/ directory using server-level configurations such as IP whitelisting if feasible within the network architecture. Additionally, implementing a Web Application Firewall with rules that detect and block unauthorized attempts to access administrative paths by non-admin users can provide a layer of compensating control. Regular security audits focusing on role-based access controls are recommended to ensure that all endpoints correctly enforce permission checks before serving sensitive data or executing privileged functions.